Table of Contents

MySQL vs PostgreSQL 차이 – 데이터 파이프라인 설계할 때 어떤 DB 선택해야 할까

데이터 파이프라인을 처음 설계하려고 앉았을 때, 저는 첫 번째 단계에서 막혔어요.

“소스 DB는 뭘 쓰지? 저장소는? MySQL? PostgreSQL?”

MySQL은 그나마 익숙하니까 그냥 쓸까 싶었는데, JSON 데이터를 통째로 넣어야 하는 상황이 자꾸 생기더라고요. API 응답값 그대로 저장하고 나중에 가공하는 패턴이었거든요. 근데 MySQL로 JSON 처리하려니 뭔가 찜찜한 느낌이 있었어요. 그러다 PostgreSQL의 JSONB라는 걸 알게 됐고, “아, 이게 다르긴 다르구나” 싶었어요.

이 글은 그때 저처럼 “그냥 아무 거나 쓰면 안 되나?” 싶은 분들을 위해, 비전공자 시각으로 MySQL과 PostgreSQL 차이를 정리한 거예요.

먼저 결론부터 – 파이프라인이라면 PostgreSQL이 더 유리해요

솔직히 말하면, 어떤 DB가 절대적으로 좋다는 건 없어요.

근데 데이터 파이프라인 아키텍처 맥락에서 보면, 저는 PostgreSQL 쪽에 손을 들어줄 수밖에 없더라고요. 이유는 글 전체에서 설명할 건데, 한 줄로 먼저 정리하면 이래요.

MySQL은 빠르고 쉽고 안정적이에요. PostgreSQL은 복잡한 데이터 구조와 분석 쿼리에 더 강해요.

파이프라인은 결국 “데이터를 어떻게 옮기고, 어떻게 쌓고, 어떻게 꺼내 쓰느냐”의 문제잖아요. 그 기준으로 보면 두 DB의 차이가 꽤 명확하게 보여요.

MySQL과 PostgreSQL, 기본 성격이 달라요

두 DB 모두 관계형 데이터베이스예요. 테이블에 행과 열로 데이터를 저장하고, SQL로 조회하는 방식이죠.

근데 태생적인 설계 철학이 달라요.

MySQL: 웹 서비스에 최적화. 빠른 읽기 속도, 단순한 구조, 쉬운 운영이 목표예요.
PostgreSQL: 복잡한 쿼리와 데이터 무결성에 강점. “객체-관계형”이라고도 불려요.

비유하자면, MySQL은 패스트푸드 가게예요. 빠르고 효율적이고 대부분의 상황에서 잘 돌아가요. PostgreSQL은 셰프가 있는 레스토랑이에요. 손이 더 가지만, 복잡한 요리(쿼리)를 훨씬 정교하게 처리할 수 있어요.

→ 단순 CRUD 위주면 MySQL, 복잡한 데이터 처리가 많으면 PostgreSQL이 유리해요.

데이터 파이프라인 관점에서 가장 중요한 차이 – JSONB

파이프라인을 만들다 보면, 반정형 데이터만 다루는 경우는 거의 없어요.

API에서 받아온 응답, 로그 데이터, 이벤트 트래킹 결과 같은 건 대부분 JSON 형태예요. 키가 고정되지 않고, 중첩 구조가 있고, 배치마다 구조가 조금씩 달라요.

MySQL도 5.7 버전부터 JSON 타입을 지원해요. 근데 솔직히 한계가 있어요. 저장은 되는데, JSON 안을 파고들어서 인덱싱하거나 조건 검색하는 게 느리고 불편해요.

PostgreSQL의 JSONB는 달라요. B가 붙은 이유가 있는데, “Binary”를 뜻해요. JSON을 텍스트로 저장하는 게 아니라 이진 형태로 파싱해서 저장해요. 덕분에 이런 게 돼요.

-- 특정 JSON 키에 인덱스 걸기
CREATE INDEX idx_user_event ON events USING GIN (payload);

-- JSON 내부 값으로 검색
SELECT * FROM events WHERE payload->>'event_type' = 'purchase';

MySQL로 이걸 비슷하게 하려면 가상 컬럼을 만들거나 별도 컬럼을 따로 파야 해요. 파이프라인에서 JSON 데이터를 자주 다룬다면, 이 차이가 굉장히 크게 느껴지더라고요.

→ JSON 데이터를 많이 다루는 파이프라인이라면, JSONB 하나만으로도 PostgreSQL 선택 이유가 충분해요.

트랜잭션 처리 방식 차이 – 파이프라인 안정성과 직결돼요

비전공자분들한테 트랜잭션은 좀 낯선 개념일 수 있어요.

쉽게 말하면, “여러 작업을 묶어서 하나처럼 처리하는 것” 이에요. 계좌 이체를 생각해보면 돼요. A 계좌에서 돈 빠지고, B 계좌에 돈 들어오는 두 작업이 동시에 성공하거나, 둘 다 실패해야 해요. 중간에 하나만 되면 큰일 나잖아요.

데이터 파이프라인도 마찬가지예요. 데이터를 읽고, 변환하고, 저장하는 과정에서 중간에 실패하면 어떻게 될지를 항상 고려해야 해요.

여기서 두 DB의 차이가 나와요.

MySQL의 트랜잭션은 InnoDB 스토리지 엔진 기준으로 잘 작동해요. 근데 기본 격리 수준(Isolation Level)이 REPEATABLE READ로 설정돼 있고, DDL(테이블 구조 변경)은 트랜잭션 안에 넣어도 자동으로 커밋돼버려요.

PostgreSQL의 트랜잭션은 DDL까지 트랜잭션에 포함돼요. 테이블 만들다가 실패하면 롤백이 돼요. 이게 파이프라인 운영할 때 생각보다 중요하더라고요. 스키마 마이그레이션 자동화할 때 특히요.

그리고 PostgreSQL은 MVCC(다중 버전 동시성 제어) 구현이 더 정교해요. 쉽게 말하면, 여러 사람이 동시에 같은 데이터를 읽고 쓸 때 충돌 없이 잘 처리한다는 뜻이에요. 파이프라인에서 여러 워커가 동시에 데이터를 처리할 때 안정성이 더 높아요.

→ 파이프라인에서 데이터 정합성이 중요하다면, 트랜잭션 처리가 더 엄격한 PostgreSQL이 안전해요.

SQL 방언 호환성 – 취준생이 꼭 알아야 하는 부분

취준생 입장에서 이게 은근히 중요한 포인트예요.

MySQL과 PostgreSQL은 둘 다 SQL을 쓰지만, 문법이 미묘하게 달라요. 이걸 SQL 방언(Dialect) 차이라고 해요.

-- 현재 날짜/시간 가져오기
-- MySQL
SELECT NOW();  -- 또는 SYSDATE()

-- PostgreSQL
SELECT NOW();  -- 또는 CURRENT_TIMESTAMP

이 정도는 비슷해 보여도, 문자열 처리나 날짜 연산, 윈도우 함수 쪽으로 가면 차이가 좀 더 커져요.

-- 문자열 합치기
-- MySQL
SELECT CONCAT(first_name, ' ', last_name) FROM users;

-- PostgreSQL (|| 연산자 사용 가능)
SELECT first_name || ' ' || last_name FROM users;

취준생 관점에서 왜 이게 중요하냐면, Airflow, dbt, Spark 같은 데이터 파이프라인 도구들이 어떤 DB 방언을 기본으로 쓰는지가 달라요. dbt는 PostgreSQL 방언 기준으로 시작한 도구예요. 실무에서 dbt를 많이 쓰는데, 처음부터 PostgreSQL 친화적인 환경에서 공부하면 나중에 덜 헷갈려요.

→ 데이터 엔지니어링 도구 생태계와의 호환성 면에서도, PostgreSQL이 파이프라인에 더 자연스럽게 맞아요.

그럼 MySQL은 언제 쓰나요?

MySQL을 무시하자는 게 절대 아니에요.

오히려 이런 상황에선 MySQL이 더 나은 선택이에요.

웹 서비스의 운영 DB(OLTP) 로 쓸 때: 트래픽이 많고 단순 읽기/쓰기가 주를 이루는 환경
레거시 시스템과 연동할 때: 기존 인프라가 MySQL 기반이면 PostgreSQL로 바꾸는 비용이 더 클 수 있어요
운영 난이도를 낮춰야 할 때: MySQL이 전반적으로 설정이 단순하고 관리가 쉬워요
클라우드 RDS에서 범용 DB 쓸 때: AWS RDS MySQL은 레퍼런스가 엄청 많아요

파이프라인에서도 소스 DB가 MySQL인 경우는 엄청 많아요. MySQL에서 데이터를 읽어와서 PostgreSQL 기반 데이터 웨어하우스에 적재하는 패턴이 실무에서 자주 보이는 구성이에요.

→ MySQL은 나쁜 DB가 아니에요. 파이프라인의 저장/분석 레이어엔 PostgreSQL, 서비스 운영 레이어엔 MySQL이 자연스러운 조합이에요.

비전공자 취준생 입장에서 정리하면

처음에 저도 “둘 다 SQL 쓰는 거 아니야?” 하고 대충 넘어가려 했어요.

근데 파이프라인 설계를 직접 해보니까 차이가 체감되더라고요. JSON 처리 하나만 해도, 트랜잭션 안정성 하나만 해도 선택이 달라져요.

정리해볼게요.

비교 항목	MySQL	PostgreSQL
JSON 처리	제한적	JSONB로 강력 지원
트랜잭션	안정적, DDL 제외	DDL 포함 완전한 트랜잭션
SQL 방언	자체 방언 있음	표준 SQL에 가까움
분석 쿼리	단순 OLTP 강점	복잡한 분석 쿼리 강점
파이프라인 도구 호환	보통	dbt 등과 높은 호환성
학습 난이도	쉬운 편	상대적으로 복잡

데이터 파이프라인 아키텍처를 설계한다면, 저는 저장/가공/분석 레이어엔 PostgreSQL을 추천드려요.

물론 소스 시스템이 MySQL이면 그건 그냥 두면 되고요. 두 DB를 다 알아두는 게 취준생 입장에서 확실히 유리해요. 어떤 회사 가도 둘 다 쓰고 있을 확률이 높거든요.

처음엔 낯설어도 PostgreSQL 로컬에 한 번 띄워보고, 간단한 파이프라인 프로젝트에 연결해보면 금방 손에 익어요. 저도 그렇게 시작했고, 지금은 확실히 “왜 PostgreSQL인가”에 대해 말할 수 있게 됐어요.

관계형 데이터베이스 선택할 때 MySQL vs PostgreSQL – 파이프라인이라면 왜 PostgreSQL일까