> "그냥 익숙한 거 쓰면 되는 거 아냐?"<br>물론 토이 프로젝트라면 그렇습니다. 하지만 엔터프라이즈 레벨로 넘어가면 **DB 엔진의 아키텍처 차이**가 서비스의 운명을 가르기도 합니다.<br>오늘은 관계형 데이터베이스(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: 아키텍처 관점에서 본 승자는?

댓글 0

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