> "그냥 익숙한 거 쓰면 되는 거 아냐?" 물론 토이 프로젝트라면 그렇습니다. 하지만 엔터프라이즈 레벨로 넘어가면 **DB 엔진의 아키텍처 차이**가 서비스의 운명을 가르기도 합니다. 오늘은 관계형 데이터베이스(RDBMS)의 3대장, **PostgreSQL, MySQL, Oracle**을 기술적인 관점(Process, MVCC, Join, SQL)에서 적나라하게 비교해 봅니다.

# 1. 프로세스 vs 스레드 (Concurrency Model)

가장 근본적인 아키텍처 차이입니다.

### 🐘 PostgreSQL: Process 기반
* **구조**: 클라이언트 연결 하나당 OS 프로세스(`postgres`) 하나를 띄웁니다.
* **장점**: 프로세스 간 메모리가 완벽히 격리되어 있어, 하나가 죽어도 전체 DB는 끄떡없습니다 (안정성 甲).
* **단점**: 프로세스 생성 비용이 비쌉니다. (Connection Pool 필수)

### 🐬 MySQL (InnoDB): Thread 기반
* **구조**: 하나의 프로세스(`mysqld`) 안에서 여러 스레드가 동작합니다.
* **장점**: 스레드 생성 비용이 매우 저렴합니다. 연결이 많아도 가볍게 처리합니다.
* **단점**: 스레드 하나가 메모리를 잘못 건드리면 프로세스 전체가 죽을 수 있습니다 (이론상).

### 🏛 Oracle: Process 기반 (Linux 기준)
* PostgreSQL과 유사하게 프로세스 기반이지만, **SGA(System Global Area)**라는 거대한 공유 메모리 영역을 매우 정교하게 관리합니다.

# 2. MVCC 구현 방식 (UPDATE의 비밀)

동시성 제어를 위해 **Multi-Version Concurrency Control**을 어떻게 구현했는가?

### 🐘 PostgreSQL: Append Only
* **방식**: `UPDATE`를 하면 기존 데이터를 지우지 않고 **새 데이터를 추가**합니다. (구버전은 `xmax` 마킹)
* **특징**: 롤백이 엄청나게 빠릅니다. 하지만 쓰레기(Dead Tuple)가 쌓여서 **VACUUM**이 필수입니다.

### 🐬 MySQL (InnoDB): Undo Log
* **방식**: 새 데이터로 덮어쓰고, **옛날 데이터는 Undo Log라는 별도 공간**으로 옮깁니다.
* **특징**: 데이터 페이지가 깨끗하게 유지됩니다(VACUUM 불필요). 하지만 트랜잭션이 길어지면 Undo Log가 넘쳐서 성능이 급락할 수 있습니다.

### 🏛 Oracle: Undo Segment
* MySQL과 비슷하게 Undo 데이터를 별도 저장하지만, 이를 **Circular Buffer** 형태로 관리하여 매우 효율적입니다. (역시 돈값 합니다)

# 3. Join 알고리즘과 Optimizer

복잡한 쿼리를 얼마나 똑똑하게 처리하는가?

### 🐘 PostgreSQL
* **알고리즘**: `Nested Loop`, `Hash Join`, `Merge Join` 모두 지원.
* **Optimizer**: **학계 정석**에 가깝습니다. 통계 정보를 기반으로 매우 정확한 실행 계획을 짭니다. 복잡한 쿼리(Subquery, CTE, Window Function) 처리에 있어서는 오픈소스 중 최강입니다.

### 🐬 MySQL
* **알고리즘**: 오랫동안 `Nested Loop Join`만 지원하다가, 8.0부터 `Hash Join`이 추가되었습니다.
* **Optimizer**: 단순한 OLTP 쿼리에 최적화되어 있습니다. 복잡한 분석용 쿼리(OLAP)는 PostgreSQL보다 느린 경우가 많습니다.

# 4. 확장성 (Extensibility)

### 🐘 PostgreSQL: "DB를 만드는 프레임워크"
* **PostGIS**: 지리 정보 시스템(GIS)의 사실상 표준.
* **pgvector**: 벡터 DB 기능 추가.
* **Custom Type**: 사용자가 직접 데이터 타입을 만들 수 있습니다.
* 이 놀라운 확장성 덕분에 "개발자가 사랑하는 DB 1위"를 놓치지 않습니다.

### 🐬 MySQL: "웹 서비스의 표준"
* 확장성보다는 **복제(Replication)**와 **HA(고가용성)** 구축이 쉽고 레퍼런스가 압도적으로 많습니다. 웹 서비스 백엔드로서는 가장 무난한 선택입니다.

# 5. 요약: 뭘 써야 할까?

| 특징 | PostgreSQL | MySQL | Oracle |
| :--- | :--- | :--- | :--- |
| **적합한 용도** | 복잡한 쿼리, 데이터 분석, 지리 정보, R&D | 단순/대량 트랜잭션, 웹 서비스, 스타트업 | 금융권, 대규모 엔터프라이즈, 미션 크리티컬 |
| **SQL 표준** | 매우 준수함 (Standard-Compliant) | 다소 독자적임 (유연함) | 표준 + 강력한 PL/SQL |
| **비용** | 무료 (BSD) | 무료 (GPL) / 유료 (Enterprise) | **매우 비쌈** |

**결론**: 
돈이 넘쳐난다면 **Oracle**,
복잡한 데이터 모델과 분석이 필요하다면 **PostgreSQL**,
빠르게 치고 나가는 웹 서비스라면 **MySQL**을 추천합니다.

(하지만 최근 트렌드는 PostgreSQL이 MySQL의 파이를 꽤 많이 가져오는 추세입니다. 😉)

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

> "MySQL이랑 PostgreSQL이랑 뭐가 달라요?" 면접에서 가장 많이 나오는 질문 중 하나이자, 시스템 아키텍처를 설계할 때 가장 고민되는 지점입니다. 단순히 "Postgres가 기능이 더 많다" 정도가 아니라, **내부적으로 데이터를 어떻게 저장하고 관리하는지**를 이해해야 진짜 성능을 끌어낼 수 있습니다. 이 글에서는 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

이 주제의 기록

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

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