MySQL vs PostgreSQL 2026 선택 가이드

MySQL과 PostgreSQL, 2026년에도 여전히 고민되는 이유

두 RDBMS의 현재 위치

2026년 현재, MySQL과 PostgreSQL은 여전히 오픈소스 관계형 데이터베이스 시장의 양대 산맥다. DB-Engines 랭킹에서도 늘 상위권을 차지하고 있고, 스타트업부터 대기업까지 실무에서 가장 많이 마주치는 RDBMS이기도 하죠. 그런데 재미있는 점은, 최근 몇 년간 PostgreSQL의 채택률이 눈에 띄게 증가했다는 겁니다. 그렇다고 MySQL이 밀린 건 아닙니다. 각각의 강점이 뚜렷해서 오히려 선택이 더 어려워졌어요.

왜 아직도 비교 글이 필요한가

솔직히 말하면, "아무거나 써도 된다"는 답은 맞기도 하고 틀리기도 한다. 간단한 CRUD 앱이라면 정말 아무거나 써도 된다. 하지만 프로젝트 규모가 커지고, 데이터 구조가 복잡해지고, 트래픽이 늘어나면 그때부터 차이가 체감되기 시작한다. 저도 두 데이터베이스를 모두 운영해본 입장에서, 처음 선택을 잘 해두면 나중에 마이그레이션 고생을 피할 수 있다고 확신한다.

핵심 차이점 한눈에 보기

장단점 비교표

아키텍처 철학의 차이

MySQL은 "빠르고 심플하게"라는 철학을 갖고 있다. InnoDB 스토리지 엔진 중심으로 동작하고, 설정할 것도 상대적으로 적다. 반면 PostgreSQL은 "정확하고 유연하게"를 추구한다. 사용자 정의 타입, 함수, 연산자까지 만들 수 있어서 사실상 데이터베이스 안에 작은 애플리케이션을 만들 수 있는 수준이다. 이 철학 차이가 실무에서의 경험을 완전히 다르게 만듭니다.

2026년 주목할 변화들

MySQL 쪽에서는 HeatWave를 통한 분석 워크로드 통합이 눈에 띄고, MySQL 9.x에서의 JavaScript 저장 프로시저 지원 같은 실험적 기능도 흥미롭다. PostgreSQL 쪽은 pg_vector 익스텐션 덕분에 AI/ML 임베딩 저장소로 활용되는 사례가 폭발적으로 늘었다. 벡터 검색이 필요한 RAG 파이프라인에서 PostgreSQL이 사실상 표준처럼 쓰이고 있는 상황이에요. 이런 트렌드가 RDBMS 비교에서 PostgreSQL에 상당한 가점을 주고 있다.

어떤 쿼리를 돌리는지가 답을 정한다

기능 목록을 나란히 놓고 고르면 결론이 안 난다. 둘 다 웬만한 건 다 되기 때문이다. 실무에서 갈리는 지점은 내가 주로 어떤 쿼리를 돌리는가다. 아래 네 가지가 실제 선택을 정하는 경우가 많다.

• 단순 조회가 대부분이다 — 기본키로 한 행 가져오고, 목록 페이지네이션하고, 가끔 조인 한 번. 이 패턴이면 MySQL이 편하다. 설정할 것이 적고 튜닝 자료도 훨씬 많다.
• 조인과 집계가 무겁다 — 서브쿼리가 겹치고 윈도우 함수를 쓰고 CTE로 단계를 나눈다면 PostgreSQL의 플래너가 눈에 띄게 낫다. 같은 쿼리에서 실행 계획이 더 영리하게 나온다.
• JSON을 본격적으로 다룬다 — 여기는 비교가 안 된다. PostgreSQL의 JSONB는 인덱싱이 되고 부분 갱신도 된다. MySQL의 JSON 타입은 저장은 되지만 그 위에 인덱스를 얹는 방식이 제한적이다.
• 공간 정보·벡터·전문 검색이 필요하다 — PostGIS, pg_vector, 전문 검색 확장까지 익스텐션으로 붙는다. 별도 엔진을 하나 더 운영하지 않아도 되는 것이 실질적인 이득이다.

반대로 MySQL이 더 나은 자리도 분명히 있다. 매니지드 서비스의 선택지가 넓고, 대량 INSERT가 계속 들어오는 로그성 워크로드에서 안정적이며, 무엇보다 운영 경험을 가진 사람을 구하기 쉽다. 팀에 DBA가 없다면 이 마지막 항목이 기술적 우열보다 크게 작용한다.

옮길 때 실제로 걸리는 것들

「나중에 옮기면 되지」라고 생각하기 쉬운데, 데이터를 옮기는 일 자체는 도구가 해 준다. 오래 걸리는 것은 애플리케이션 쪽이다. 두 데이터베이스를 모두 운영해 보면 아래 다섯 가지에서 시간이 간다.

• 대소문자 처리 — MySQL은 기본 콜레이션이 대소문자를 구분하지 않는다. PostgreSQL은 구분한다. 로그인 아이디 비교 같은 곳에서 조용히 동작이 달라진다.
• 자동 증가 키 — AUTO_INCREMENT와 SERIAL/IDENTITY는 개념은 같지만 문법과 시퀀스 관리 방식이 다르다.
• 비표준 문법 — INSERT ... ON DUPLICATE KEY UPDATE는 ON CONFLICT DO UPDATE로, LIMIT a, b는 LIMIT b OFFSET a로 바꿔야 한다.
• 날짜·시간 타입 — 타임존을 담는 타입의 동작이 달라서, 옮긴 뒤 시각이 몇 시간씩 밀리는 사고가 흔하다.
• ORM이 만드는 SQL — 같은 코드라도 방언에 따라 생성되는 쿼리가 다르다. 성능 특성이 통째로 바뀔 수 있으므로 느린 쿼리 로그를 다시 잡아야 한다.

그래서 실무 조언은 하나로 모인다. 옮길 계획이 조금이라도 있다면 처음부터 표준 SQL 쪽으로 붙여 둔다. 방언에 기대는 코드를 줄여 두면 나중에 드는 비용이 크게 준다.

운영에 들어가면 달라지는 것

개발 중에는 잘 안 보이다가 운영에서 드러나는 차이도 있다. 대표적인 것이 PostgreSQL의 VACUUM이다. MVCC 구조상 갱신·삭제된 행이 즉시 사라지지 않고 죽은 튜플로 남는데, 이것을 정리하는 작업이 VACUUM이다. 자동으로 돌지만 갱신이 잦은 테이블에서는 설정을 손봐야 하고, 방치하면 테이블이 계속 부풀어 오른다. MySQL을 쓰던 사람이 가장 먼저 놀라는 지점이 대개 여기다.

반대로 MySQL은 복제 지연에서 애를 먹는 경우가 많다. 읽기 부하를 리플리카로 넘겼는데 쓰기 직후 읽으면 옛 데이터가 나오는 상황이다. 두 데이터베이스 모두 겪는 문제이지만, 대응 방식과 관측 도구가 다르다.

버전 올리기의 부담도 성격이 다르다. PostgreSQL의 메이저 업그레이드는 준비가 더 필요하고, MySQL은 상대적으로 완만한 대신 세부 동작이 조용히 바뀌는 경우가 있다. 어느 쪽을 고르든 「올리는 계획」을 처음부터 세워 두는 편이 나중에 편하다.

정리하면 이렇다. 조인과 JSON과 확장이 필요하면 PostgreSQL, 단순하고 운영 인력을 구하기 쉬운 쪽이 중요하면 MySQL이다. 그리고 팀이 이미 잘 아는 쪽이 있다면 그것이 대체로 정답이다. 익숙한 도구가 실제로는 더 빨리 안정화된다.

한 가지 더. 두 데이터베이스 모두 기본 설정이 운영에 맞춰져 있지 않다. 메모리 관련 설정을 그대로 두면 장비 성능을 절반도 못 쓰는 경우가 흔하다. MySQL이라면 InnoDB 버퍼 풀 크기를, PostgreSQL이라면 공유 버퍼와 작업 메모리를 먼저 본다. 이 한 가지만 맞춰도 체감이 크게 달라지므로, 인덱스를 손보기 전에 확인할 항목이다.

마지막으로 라이선스도 짚어 둔다. PostgreSQL 라이선스는 제약이 거의 없고, MySQL은 GPL이며 Oracle이 소유하고 있다. 대부분의 웹 서비스에서는 문제가 되지 않지만, 제품에 데이터베이스를 함께 배포하는 형태라면 미리 확인해 두는 편이 안전하다.

커넥션 관리도 성격이 다르다. PostgreSQL은 연결 하나당 프로세스를 띄우기 때문에 연결 수가 늘면 메모리를 그만큼 쓴다. 그래서 커넥션 풀러를 앞에 두는 것이 사실상 표준이다. MySQL은 스레드 기반이라 이 부담이 덜하다. 서버리스 환경처럼 연결이 자주 생겼다 사라지는 구조라면 이 차이가 꽤 크게 나타난다.