[DB] MySQL 8.0이 끝났습니다 — 8.4로 올릴까 PostgreSQL로 옮길까

RDS 청구서에 못 보던 항목이 하나 늘었다는 이야기를 8월부터 자주 듣습니다. 인스턴스를 늘린 것도 아닌데 vCPU 시간만큼 요금이 붙어 있죠. MySQL 8.0을 그대로 쓰고 있는 계정이라면 그게 정상입니다.

문제는 그다음에 붙는 질문입니다. 이왕 손대는 김에 PostgreSQL로 갈아탈까, 아니면 8.4로 한 칸만 올리고 말까. 결론부터 말씀드리면 이 둘은 같은 무게의 선택지가 아닙니다. 지원 종료는 '업그레이드'의 이유이지 '엔진 전환'의 이유가 아니거든요. 엔진을 바꿀 만한 이유는 따로 있고, 그게 해당되는 팀은 소수입니다.

이 글은 두 엔진을 실제로 이관해 본 기록이 아니라, Oracle·AWS·PostgreSQL 공식 문서와 릴리스 노트에 적힌 날짜와 제약을 대조해 정리한 것입니다(확인일 2026년 9월 5일).

강제 일정은 이미 네 칸이 지나갔고 다음 칸은 2028년 8월입니다

이미 지나간 날짜와 아직 남은 날짜

헷갈리기 쉬운 게 '커뮤니티 기준 날짜'와 'RDS 기준 날짜'가 다르다는 점입니다.

시점	무슨 일
2026-04-21	Oracle이 MySQL 8.0을 Sustaining Support로 전환
2026-04-30	MySQL 8.0 커뮤니티 EOL (AWS 릴리스 캘린더 표기 기준)
2026-07-31	Amazon RDS for MySQL 8.0 표준 지원 종료
2026-08-01	RDS Extended Support 과금 시작 (Year 1 단가)
2028-08-01	Extended Support Year 3 단가로 인상
2029-07-31	Extended Support 종료 — 이후 AWS가 강제로 메이저 업그레이드

Oracle Lifetime Support Policy 문서는 Sustaining Support에 포함되지 않는 것을 "New updates, fixes, security alerts, data fixes, and critical patch updates"로 적어 뒀습니다. 신규 보안 패치가 없다는 뜻이죠. RDS는 자체 빌드로 공백을 메우는데, CVE-2026-46863을 고친 8.0.46-RDS.20260624의 Extended Support 종료일은 2027년 7월 31일로 메이저(2029-07-31)보다 훨씬 이릅니다. 돈을 내고도 마이너는 계속 따라 올려야 합니다.

요금 예시는 US East(오하이오) 기준 Year 1~2가 vCPU-시간당 $0.100, Year 3이 $0.200이고 서울 리전(ap-northeast-2) 단가는 AWS 요금 페이지에 없습니다. 2028년 8월 1일에 단가가 두 배가 되고 Multi-AZ 대기 인스턴스에도 부과된다는 구조가 더 확실한 근거죠. 계산 방식은 MySQL 8.0을 그냥 두면 RDS 요금이 붙습니다에 정리해 뒀습니다.

그럼 최신 LTS로 한 번에 올리면 되지 않나요

안 됩니다. 여기서 계획이 자주 어긋납니다.

MySQL 레퍼런스 매뉴얼은 "다음 LTS 시리즈로의 업그레이드는 지원하지만 LTS 시리즈를 건너뛰는 것은 지원하지 않는다"고 적고 있습니다. 8.4.x에서 9.7.x는 되지만 8.0에서 9.7로 직행하는 경로는 없죠. 관리형에는 제약이 한 겹 더 붙습니다. RDS가 지원하는 메이저 업그레이드 경로는 5.7 → 8.0, 8.0 → 8.4 두 가지뿐이고, 9.7·9.6·9.5는 Database Preview 환경에만 있습니다. Preview 인스턴스는 생성 60일 뒤 백업·스냅샷까지 삭제되고 프로덕션 사용이 금지돼 있고요.

Amazon RDS의 MySQL 메이저 버전 지원 일정 표 (확인일 2026-09-05)

버전 번호 읽는 법도 올해 바뀌었습니다. 9.7.0(2026-04-21)부터가 LTS이고 순차 번호를 쓰는 마지막 라인도 9.7입니다. 그 뒤로는 YY.M 캘린더 버저닝이라 26.7은 2026년 7월에 나온 Innovation 릴리스죠. Oracle Lifetime Support Policy 표 기준 Extended 종료는 8.4 LTS가 2032년 4월, 9.7 LTS가 2034년 4월입니다.

릴리스 번호를 받아 적을 때 함정이 하나 있습니다. 2026년 8월 18일에 8.4.12, 9.7.3, 26.7.1이 한꺼번에 나왔는데 셋 다 릴리스 노트에 "This release is a Critical Security Patch Update for the MySQL Server docker image, only."라고 적힌 Docker 이미지 전용 보안 패치입니다. tarball이나 RPM·DEB로 8.4.12를 받으러 가면 없습니다. 각 라인의 최신 정규 유지보수 릴리스는 8.4.11 / 9.7.2 / 26.7.0이고 셋 다 2026년 7월 28일자죠. 8.4의 2026년 릴리스가 1월 20일, 4월 21일, 6월 16일, 7월 28일, 8월 18일에 나온 걸 보면 순수한 분기 주기가 아니라 분기 유지보수에 수시 보안 패치가 얹히는 구조입니다.

같은 8.0인데 왜 우리는 요금이 안 붙나요

Aurora를 쓰고 계신 겁니다. 여기가 시급도를 가르는 가장 큰 갈림길이죠.

	RDS for MySQL 8.0	Aurora MySQL version 3
표준 지원 종료	2026-07-31 (종료)	2028-04-30
Extended Support 과금 시작	2026-08-01	2028-05-01
Year 3 단가 적용	2028-08-01	해당 없음
Extended Support 종료	2029-07-31	2029-07-31

같은 MySQL 8.0인데 표준 지원 종료가 21개월 차이 납니다. Aurora 쪽은 지금 추가 요금이 없고 8.4도 이미 제공 중이라(8.4.8이 2026년 9월 3일 릴리스) 이번 분기에 급할 이유가 없죠.

다만 표의 오른쪽 아래에 반전이 있습니다. Aurora v3의 연장 지원은 3년이 아니라 약 15개월입니다. Year 3 단가가 "Not applicable"인 이유가 그것이고, 최종 종료일은 RDS for MySQL 8.0과 같은 2029년 7월 31일이죠.

8.4로 올리면 그다음은 편한가요

메이저 기준으로는 2029년까지 여유가 생깁니다. 다만 RDS 마이너에도 개별 종료일이 붙어서, 8.4.11은 릴리스 2026-08-21에 표준 지원 종료 2027-08-21처럼 1년쯤 되는 유효기간이 걸려 있죠. 그리고 파라미터 그룹을 그대로 들고 가면 안 됩니다. innodb_io_capacity가 200에서 10000으로, innodb_adaptive_hash_index가 ON에서 OFF로 바뀌는 등 InnoDB 기본값이 여럿 뒤집혔거든요. mysql_native_password가 기본 비활성이라 --mysql-native-password=ON을 켜지 않으면 옛 계정은 로그인부터 실패합니다.

운영 스크립트도 깨집니다. 아래 문장들은 8.4에서 제거돼 쓰면 문법 오류가 납니다.

CHANGE MASTER TO      → CHANGE REPLICATION SOURCE TO
SHOW MASTER STATUS    → SHOW BINARY LOG STATUS
START / STOP SLAVE    → START / STOP REPLICA
SHOW SLAVE STATUS     → SHOW REPLICA STATUS
RESET MASTER          → RESET BINARY LOGS AND GTIDS

mysql_upgrade·mysqlpump 유틸리티와 expire_logs_days·default_authentication_plugin 변수도 함께 사라졌습니다.

그러면 PostgreSQL로 옮길 이유는 뭔가요

지원 종료는 이유가 못 됩니다. 그래도 축이 되는 차이는 있죠. 우선 지원 잔여기간입니다. RDS for PostgreSQL 18의 표준 지원 종료가 2031년 2월 28일이라 RDS for MySQL 8.4(2029-07-31)와 약 1년 7개월 차이가 납니다.

벡터 검색. 여기가 실제로 결정을 가르는 지점입니다. MySQL 9.7에 VECTOR 타입이 생긴 건 맞습니다. 그런데 거리 계산 함수 DISTANCE()에 대해 공식 문서가 이렇게 적어 뒀습니다. "MySQL HeatWave on OCI와 MySQL AI 사용자에게만 제공되며 MySQL Commercial 및 Community 배포판에는 포함되지 않는다."

커뮤니티 MySQL로는 벡터를 저장만 하고 검색은 못 한다는 뜻이죠. STRING_TO_VECTOR(), VECTOR_TO_STRING(), VECTOR_DIM()만 제약 없이 쓸 수 있고 VECTOR 컬럼은 어떤 종류의 키로도 못 씁니다.

MySQL 9.7 벡터 함수 문서의 DISTANCE() 제공 범위 문장 (확인일 2026-09-05)

반대편 pgvector는 HNSW와 IVFFlat 두 가지 근사 최근접 인덱스를 제공하고 거리 연산자도 <->(L2), <#>(내적), <=>(코사인) 등으로 나뉩니다. Amazon RDS for PostgreSQL 18.6·17.11·16.15·15.19에는 vector 0.8.2가 들어 있고요. 참고로 MySQL은 GPL과 상용의 이중 라이선스라 독점 애플리케이션에 바이너리를 임베드해 배포하려면 상용 라이선스가 필요한데, 패키지 제품을 파는 팀에는 이것도 결정적인 축입니다.

한국어 검색을 쓰고 있다면 방향이 반대입니다

"PostgreSQL이 검색에 강하다"는 말은 한국어에서는 그대로 성립하지 않습니다. MySQL은 CJK용 ngram 전문검색 파서를 내장하고 있거든요. ngram_token_size 기본값은 2이고 범위는 1~10이며, FULLTEXT (title, body) WITH PARSER ngram 한 줄이면 끝납니다.

반면 PostgreSQL 18 공식 문서의 텍스트 검색 사전 목록에는 한국어 설정이 없습니다. RDS에서는 pg_bigm(PG 18.6 기준 1.2_20250903)이나 pg_trgm 1.6으로 다시 설계해야 하고, 자주 언급되는 pgroonga는 RDS 지원 확장 목록에 없습니다. 검색 품질 회귀 테스트 없이 옮기면 서비스 지표가 먼저 깨집니다.

JPA를 쓰니까 DB를 바꿔도 코드는 그대로일까요

이 기대가 가장 자주 깨집니다. Hibernate 7.4 공식 입문 가이드는 GenerationType.AUTO가 "식별자 타입과 데이터베이스 기능에 따라 SEQUENCE, TABLE, UUID 중에서 선택된다"고 설명합니다. 이 목록에 IDENTITY는 없죠. 시퀀스가 없는 MySQL과 있는 PostgreSQL에서 같은 엔티티 코드가 다른 전략으로 귀결됩니다. AUTO에 맡기지 말고 명시하시는 편이 안전합니다.

upsert는 JPA 표준에 없어 네이티브 쿼리로 쓰는 부분이라 그대로 옮겨지지 않고요.

-- MySQL 9.7 (VALUES(col) 참조는 폐기 예정이라 AS new 별칭)
INSERT INTO stock (sku, qty) VALUES ('A-1', 10) AS new
  ON DUPLICATE KEY UPDATE qty = stock.qty + new.qty;

-- PostgreSQL 18 (conflict_target 필수)
INSERT INTO stock (sku, qty) VALUES ('A-1', 10)
  ON CONFLICT (sku) DO UPDATE SET qty = stock.qty + EXCLUDED.qty;

MySQL 문서는 유니크 인덱스가 여러 개인 테이블에서는 ON DUPLICATE KEY UPDATE를 피하라고 명시합니다. 여러 행이 매칭돼도 한 행만 갱신되기 때문이죠. 이런 네이티브 쿼리가 코드에 흩어져 있는지가 작업량을 좌우하는데, 그 기준은 JPA냐 MyBatis냐에서 정리한 내용과 그대로 이어집니다.

요금이 붙는지, 벡터 검색이 필요한지 두 질문으로 갈립니다

자주 보는 오해 네 가지

"관리형이니까 AWS가 알아서 안전하게 올려 준다." Extended Support는 자동 등록되지만 무료가 아닙니다. 반대로 EngineLifecycleSupport를 끄면 표준 지원이 끝난 인스턴스는 다음 지원 메이저로 자동 업그레이드됩니다. 가만히 두면 안전하다도, 가만히 두면 공짜다도 둘 다 틀립니다.

"MySQL 9.x는 실험용 Innovation이라 프로덕션에 못 쓴다." 9.7.0부터 LTS입니다. 다만 RDS에서 9.7은 Preview 전용이라 GA를 기다리며 8.0에 머무는 동안 요금만 쌓입니다.

"PostgreSQL은 DDL이 트랜잭션 안에서 도니까 무중단 스키마 변경이 자유롭다." 트랜잭션 DDL과 무중단은 별개입니다. 명시적 예외를 빼면 ALTER TABLE은 ACCESS EXCLUSIVE 잠금을 잡고 타입 변경은 전체 재작성을 유발하죠. CREATE INDEX CONCURRENTLY는 오히려 트랜잭션 블록 안에서 못 돌리고 실패하면 INVALID 인덱스가 남습니다.

"성능은 어느 쪽이 더 빠르다." 공식 문서로 확정할 수 있는 건 기능의 유무, 기본값, 잠금 동작까지입니다. 워크로드별 비교 수치는 확보하지 못해 축에서 뺐습니다.

지금 옮길 팀, 기다려도 되는 팀, 하면 안 되는 상황

지금 움직여야 하는 팀

• RDS(비-Aurora)에서 MySQL 8.0을 돌리는 팀. 이미 과금 중이고 2028년 8월 1일에 단가가 두 배가 됩니다. 기본 행동은 엔진 전환이 아니라 8.4로 메이저 업그레이드입니다.
• 온프레미스·EC2에서 8.0을 자체 운영하는 팀. 2026년 4월 21일 이후 커뮤니티 보안 패치 경로가 없습니다.
• 벡터 유사도 검색이 로드맵에 확정된 팀. 이 팀만 PostgreSQL 18 + pgvector 전환을 같은 창에서 함께 검토할 가치가 있습니다.

기다려도 되는 팀

• Aurora MySQL version 3 사용 팀. 지금 추가 요금이 없습니다. 다만 최종 마감은 RDS와 같은 2029년 7월 31일이죠.
• PostgreSQL 15~17 사용 팀. 각각 2027-11-11, 2028-11-09, 2029-11-08까지 남았습니다. 반대로 13 이하라면 지금이 움직일 때고요.
• 정형 CRUD 위주라 JSON·전문검색·벡터 요구가 없는 서비스. 8.4로 올린 뒤 다음 LTS 창에서 재평가하시면 됩니다.

하면 안 되는 것

• "EOL이 왔으니 PostgreSQL로 간다"는 결정. upsert 쿼리, 식별자 생성 전략, 복제·백업·모니터링 도구, DDL 운영 절차까지 전부 다시 만드는 작업입니다.
• 한국어 전문검색을 ngram FULLTEXT에 의존하는 서비스가 품질 회귀 테스트 없이 이전하는 것.
• 8.0 파라미터 그룹을 그대로 들고 8.4로 올리는 것. 인증이 끊기고 InnoDB 성능 특성이 달라집니다.

옮기기 전 확인 목록

[ ] RDS 인가 Aurora 인가 → RDS 면 이미 과금 중, Aurora 면 2028-04-30 까지 유예
[ ] Multi-AZ 인가 → 대기 인스턴스에도 Extended Support 요금이 붙는다
[ ] 현재 마이너 버전의 Extended Support 종료일을 확인했는가 (메이저와 다르다)
[ ] 8.4 용 파라미터 그룹을 새로 만들었는가 (io_capacity · adaptive_hash_index 등)
[ ] mysql_native_password 로 접속하는 계정이 있는가 → --mysql-native-password=ON 필요
[ ] SHOW MASTER STATUS / START SLAVE / mysql_upgrade / mysqlpump 를 쓰는 스크립트가 있는가
[ ] 벡터 검색이나 한국어 ngram FULLTEXT 의존이 있는가 → 엔진 전환 판단의 갈림길
[ ] @GeneratedValue(AUTO) 와 ON DUPLICATE KEY UPDATE 쿼리 목록을 뽑았는가
[ ] 목표를 8.4 로 잡았는가 (RDS 에서 9.7 은 Preview 전용)

다음에 볼 글

요금이 실제로 얼마나 붙고 계정에서 어떻게 확인하는지는 MySQL 8.0을 그냥 두면 RDS 요금이 붙습니다에 정리해 뒀습니다. 이 글의 전제가 되는 글입니다. 다음 글에서는 8.0에서 8.4로 올릴 때의 실제 절차를 다루겠습니다. 스냅샷 복원과 블루/그린 배포 중 어디를 고를지 갈리는 지점이 따로 있거든요.

이 글은 Oracle과 AWS, PostgreSQL의 공식 문서와 릴리스 노트에 적힌 날짜·기본값·제약을 기준으로 정리했습니다(확인일 2026년 9월 5일). 실제 적용하실 때는 본인 리전과 인스턴스의 버전 정보를 콘솔에서 다시 확인해 주세요. 잘못된 내용이나 보충이 필요한 부분이 있으면 댓글로 알려 주시면 반영하겠습니다.

참고한 자료

• MySQL Product Support EOL Announcements · Oracle Technology Products Lifetime Support Policy(2026-08-07 발효본) (확인일 2026-09-05)
• MySQL 9.7 레퍼런스 매뉴얼 — Releases(Innovation and LTS), Vector Functions, ngram Full-Text Parser, ON DUPLICATE KEY UPDATE (확인일 2026-09-05)
• MySQL 8.4·9.7·26.7 릴리스 노트 색인 — 정규 릴리스와 Docker 전용 CSPU 구분 (확인일 2026-09-05)
• MySQL 8.4 레퍼런스 매뉴얼 「What Is New in MySQL 8.4 since 8.0」 (확인일 2026-09-05)
• Amazon RDS User Guide — MySQL on Amazon RDS versions, Extended Support charges (확인일 2026-09-05)
• Release calendars for Amazon Aurora MySQL · Amazon RDS for PostgreSQL (확인일 2026-09-05)
• Amazon RDS for MySQL Pricing — US East(오하이오) 기준 Extended Support 단가 (확인일 2026-09-05)
• PostgreSQL Versioning Policy · 18 Release Notes · ALTER TABLE · CREATE INDEX · INSERT (확인일 2026-09-05)
• pgvector README · Hibernate ORM 7.4 An Introduction to Hibernate 7 (확인일 2026-09-05)