PostgreSQL vs MySQL vs Oracle: 아키텍처 관점에서 본 승자는?

> "MySQL이랑 PostgreSQL이랑 뭐가 달라요?"<br>면접에서 가장 많이 나오는 질문 중 하나이자, 시스템 아키텍처를 설계할 때 가장 고민되는 지점입니다.<br>단순히 "Postgres가 기능이 더 많다" 정도가 아니라, **내부적으로 데이터를 어떻게 저장하고 관리하는지**를 이해해야 진짜 성능을 끌어낼 수 있습니다.<br>이 글에서는 PostgreSQL을 지탱하는 **4가지 핵심 기둥(MVCC, WAL, VACUUM, Buffer)**을 아주 상세하게 파헤쳐 봅니다.

# 1. 아키텍처 개요: 프로세스 기반 모델

MySQL이 스레드(Thread) 기반인 것과 달리, PostgreSQL은 **프로세스(Process) 기반**입니다.
클라이언트 연결이 들어올 때마다 `postgres` 메인 프로세스(Postmaster)가 새로운 자식 프로세스(Backend Process)를 `fork()`합니다.

*   **장점**: 프로세스 간 메모리가 격리되어 있어, 하나가 죽어도 전체 DB가 죽지 않습니다. 안정성이 매우 높습니다.
*   **단점**: 연결 생성 비용이 비쌉니다. 그래서 **PgBouncer** 같은 Connection Pooler가 사실상 필수입니다.

# 2. MVCC (Multi-Version Concurrency Control)

동시성을 제어하는 PostgreSQL의 심장입니다. **"읽는 자는 쓰는 자를 막지 않고, 쓰는 자는 읽는 자를 막지 않는다"**는 원칙을 지킵니다.

### 🛠 동작 원리: UPDATE는 사실 INSERT다?

MySQL(InnoDB)은 Undo Log를 사용해 이전 버전을 관리하지만, PostgreSQL은 **데이터 페이지(Heap)에 튜플의 예전 버전과 새 버전을 함께 저장**합니다.

1.  데이터를 `UPDATE` 하면, 기존 행을 덮어쓰는 게 아니라 **새로운 행(New Tuple)을 추가**합니다.
2.  기존 행(Old Tuple)은 `xmax` 필드에 "삭제된 트랜잭션 ID"를 마킹하고 투명인간 취급합니다.
3.  각 트랜잭션은 자신의 시작 시점에 따라 어떤 버전을 볼지(`xmin`, `xmax`) 결정합니다.

이 구조 덕분에 롤백(Rollback)이 매우 빠르지만, 치명적인 부작용이 생깁니다. 바로 **Bloat(비만) 현상**입니다. (뒤에서 다룰 VACUUM이 필요한 이유)

# 3. VACUUM: 쓰레기 청소부

앞서 말했듯, `UPDATE`나 `DELETE`가 발생하면 디스크에는 "죽은 튜플(Dead Tuple)"이 계속 쌓입니다. 이걸 방치하면 테이블 크기가 무한히 커지고 조회 속도가 느려집니다.

### 🧹 AutoVacuum
PostgreSQL은 백그라운드에서 주기적으로 `AutoVacuum` 데몬을 실행하여 죽은 튜플을 청소하고, 해당 공간을 **재사용 가능하도록 마킹(FSM: Free Space Map)**합니다.

*   **주의할 점**: 일반 `VACUUM`은 OS에게 디스크 공간을 반납하지 않습니다. (파일 크기가 줄어들지 않음)
*   **VACUUM FULL**: 디스크 공간을 완전히 회수하지만, 테이블에 **Exclusive Lock**을 걸어버려서 운영 중엔 절대 쓰면 안 됩니다.

# 4. WAL (Write-Ahead Logging): 데이터의 생명줄

데이터베이스의 가장 중요한 미덕은 **"전원이 뽑혀도 데이터는 날아가면 안 된다"**입니다. 이를 보장하는 것이 WAL입니다.

### 📝 동작 방식
1.  데이터를 변경하면, 실제 디스크 파일(Heap)을 고치기 전에 먼저 **WAL 로그 파일**에 변경 내용을 순차적으로(Sequential) 기록합니다.
2.  `fsync()`를 통해 WAL이 디스크에 안전하게 저장된 것이 확인되면 클라이언트에게 "성공" 응답을 보냅니다.
3.  실제 데이터 파일(Data File)은 나중에 백그라운드 프로세스(`Checkpointer`)가 천천히 변경합니다.

이 WAL 파일은 **Replication(복제)**의 핵심이기도 합니다. Master DB가 Slave DB에게 이 WAL 스트림을 쏘아주면, Slave가 그걸 받아 똑같이 재현(Replay)하는 방식입니다.

# 5. Shared Buffer: 메모리 관리

PostgreSQL은 자체적인 캐시 영역인 **Shared Buffer**를 관리합니다. 하지만 특이하게도 OS의 파일 시스템 캐시(Page Cache)와 이중으로 캐싱하는 구조(Double Buffering)를 가집니다.

*   **튜닝 포인트**: 보통 전체 RAM의 **25~40%** 정도를 `shared_buffers`에 할당하는 것이 권장됩니다. (너무 많이 주면 OS 캐시 효율이 떨어짐)

# 6. TOAST (The Oversized-Attribute Storage Technique)

PostgreSQL의 페이지 크기는 기본 8KB입니다. 만약 8KB보다 큰 데이터(긴 텍스트나 이미지 등)가 들어오면 어떻게 할까요?
PostgreSQL은 이를 자동으로 압축하고 조각내어 별도의 **TOAST 테이블**에 저장합니다. 사용자는 이를 의식하지 않고 그냥 쓰면 됩니다.

# 마치며

PostgreSQL은 "대학원생들이 만든 DB"라는 별명처럼 학구적이고 정교하게 설계되어 있습니다.

1.  **MVCC** 덕분에 동시성이 뛰어나지만,
2.  **Dead Tuple** 때문에 **AutoVacuum** 튜닝이 필수적이며,
3.  **WAL**을 통해 강력한 데이터 무결성과 복제를 지원합니다.

이 원리들을 이해하고 나면, `vacuum_cost_limit` 같은 설정값이 왜 존재하는지, 왜 대량 `UPDATE`를 조심해야 하는지 비로소 보이기 시작할 것입니다. 🐘

PostgreSQL 완벽 가이드: MVCC부터 WAL까지 아키텍처 깊게 파기

독자의 메모