PostgreSQL 18과 MySQL 8.4 LTS 업데이트 비교: 개발자가 알아야 할 핵심 변화

관계형 데이터베이스의 양대 축인 PostgreSQL과 MySQL이 각각 굵직한 분기점을 맞이했습니다. PostgreSQL은 18 버전을 통해 데이터베이스 내부 입출력 아키텍처와 식별자 생성 방식을 근본적으로 개선했고, MySQL은 첫 공식 장기 지원 버전인 8.4 LTS와 AI 벡터 기능을 실험하는 9.0 혁신 릴리스 체계로 재편되었습니다.

웹 백엔드를 설계하거나 인프라를 운영하는 개발자에게 이번 변화는 실무 체감이 큰 요소들을 담고 있습니다. 두 진영이 어떤 성능 문제를 해결하려 했는지, 애플리케이션 코드와 스키마 설계에 어떤 영향을 주는지 살펴봅니다.

비동기 I/O와 기본 내장 UUIDv7을 품은 PostgreSQL 18

PostgreSQL 18의 가장 큰 내부 변화는 네이티브 비동기 I/O 하위 시스템의 도입입니다. 기존에는 디스크에서 대량의 데이터를 읽어올 때 운영체제 수준의 버퍼링이나 동기식 I/O 호출에 의존하는 구조라 병목이 발생하기 쉬웠습니다. 비동기 I/O 서브시스템이 코어에 안착하면서 디스크 사용량이 많은 순차 탐색과 백큠(VACUUM) 작업 처리량이 기존 대비 2배에서 최대 3배까지 향상되었습니다.

애플리케이션 개발자에게 직접 와닿는 변화는 기본 내장 uuidv7() 함수입니다. 기존 UUID v4는 무작위 값으로 생성되어 B-Tree 인덱스에 삽입될 때 디스크 페이지 분할과 단편화를 심하게 유발했습니다. 시간 순서로 정렬되는 UUIDv7이 엔진 표준 함수로 들어가면서 외부 확장 프로그램 없이도 정렬 성능과 고유 식별자의 장점을 함께 얻게 되었습니다.

PostgreSQL 18에서 UUIDv7을 기본 키 기본값으로 설정하는 테이블 정의 예시입니다.

외부 라이브러리나 pg\_uuidv7 확장을 설치하지 않아도 시계열 인덱스 성능이 유지되는 기본 키를 즉시 생성할 수 있습니다.

데이터 무결성 측면에서는 initdb 클러스터 생성 시 데이터 체크섬 옵션이 기본 활성화 상태로 변경되었습니다. 디스크 손상으로 인한 데이터 왜곡을 조기에 감지할 수 있어 운영 안정성이 높아졌습니다. 표준 SQL/JSON 지원도 확대되어 반정형 JSON 데이터를 관계형 테이블 컬럼 형태로 곧바로 프로젝션하는 JSON\_TABLE() 함수를 복잡한 가공 스크립트 없이 쿼리 안에서 사용할 수 있습니다.

인증 보안 강화와 벡터 지원을 분리한 MySQL 8.4 LTS 및 9.0

오라클의 새로운 릴리스 모델에 따라 출시된 MySQL 8.4 LTS는 안정성과 엄격한 보안을 최우선으로 둡니다. 가장 두드러진 변화는 레거시 인증 플러그인인 mysql\_native\_password가 기본값에서 비활성화된 점입니다. 신규 설치 및 업그레이드 환경에서는 더 안전한 caching\_sha2\_password가 강제 적용됩니다. 오래된 데이터베이스 클라이언트를 유지하는 서비스라면 연결 에러가 발생할 수 있어 드라이버 호환성 점검이 선행되어야 합니다.

스키마 제약 조건도 엄격해졌습니다. 부동소수점 타입인 FLOAT과 DOUBLE 컬럼에 AUTO\_INCREMENT 속성을 부여하던 과거의 위험한 문법이 완전히 제거되었으며 파티셔닝 키에 대한 인덱스 접두사 지정도 제한됩니다. 헐거운 데이터 모델링을 허용하던 관행을 차단하고 런타임 예측 불가능성을 줄이려는 의도입니다.

기능 실험을 담당하는 MySQL 9.0 혁신 릴리스에서는 임베딩 데이터를 다루기 위한 네이티브 VECTOR 데이터 타입이 추가되었습니다. 최대 16,383차원의 부동소수점 배열을 컬럼으로 정의하고 전용 헬퍼 함수를 통해 문자열과 벡터 간 상호 변환을 수행할 수 있습니다.

복잡한 별도 벡터 엔진을 즉시 구축하기 부담스러운 단계에서 간단한 AI 임베딩 검색 파이프라인을 검증할 때 가볍게 활용해볼 수 있는 진입로를 열어줍니다.

실무에서 어떤 엔진과 기능을 고려해야 할까

대규모 분석 쿼리와 인덱스 단편화 방지, 표준 SQL/JSON 변환이 잦은 환경이라면 PostgreSQL 18의 변화가 강력한 이점을 제공합니다. 특히 B-Tree 인덱스 쓰기 성능을 보호하면서 범용 식별자를 써야 하는 분산 서비스 아키텍처라면 내장 uuidv7() 함수 하나만으로도 버전 마이그레이션 가치가 충분합니다.

안정적인 장기 운영이 목표인 엔터프라이즈 환경에서 MySQL을 선택한다면 8.4 LTS로 전환하면서 오래된 연결 라이브러리를 최신화하고 비권장 스키마 구조를 정리하는 작업이 권장됩니다. 벡터 검색 기반의 가벼운 PoC가 필요하다면 MySQL 9.0의 네이티브 벡터 타입을 로컬 환경에서 테스트해보며 기능 확장을 가늠해보는 접근이 유용합니다.