PostgreSQL은 왜 이건 아직 못 할까: Momjian이 짚은 코어의 빈칸들

들어가며

PostgreSQL은 매년 약 200개의 기능과 변경을 더하지만, “이건 당연히 되겠지” 싶은 큰 기능 몇 개는 30년째 코어에 비어 있어요. sharding, connection pooling, 내장 암호화(TDE)처럼 상용 DB라면 체크리스트에 들어가는 항목들인데, PostgreSQL을 쓰다 보면 어느 순간 “여기까지 다 되는데 왜 이건 안 되지” 하는 벽을 만나요.

Bruce Momjian(브루스 모미잔)은 2026년 발표 《What’s Missing in Postgres?》에서 이 빈칸들을 정면으로 다뤘습니다. 그가 발표 슬라이드를 쓰면서 깨달은 한 가지가 있습니다. 빠진 기능의 대다수는 기능(functionality)이 없어서가 아니라 성능(performance)을 위한 것이라는 점입니다. 즉 PostgreSQL은 “못 하는” 쪽이라기보다, “더 빨리 하기 위한 장치"가 아직 코어에 없는 쪽에 가깝습니다.

이 글은 그 빈칸을 항목별로 짚습니다. 각 항목마다 무엇이 없는지, 왜 코어에 없는지, 지금은 무엇으로 메우는지, 코어 편입 전망은 어떤지 차례로 봅니다. Momjian의 발표 분류를 따라 단일 호스트(single host) 성능 항목과 다중 호스트(multi-host) 항목으로 나눕니다.

한 장으로 보는 빈칸 지도

먼저 전체 그림을 표로 깔아둡니다.

표를 위에서 아래로 훑으면 패턴이 보입니다. 빈칸 대부분에 “지금 메우는 도구"가 이미 하나씩 있다는 점입니다. PostgreSQL은 코어를 작게 유지하고 extension/외부 프로세스로 확장하는 철학을 30년간 지켜 왔고, 빈칸은 그 철학의 그림자이기도 합니다.

코어와 빈칸의 경계

PostgreSQL이 무엇을 코어에 두고 무엇을 바깥에 두는지, 영역을 그림으로 나눠 봅니다.

flowchart TD
    Core["PostgreSQL 코어"]
    Core --> Q["쿼리 처리 · MVCC"]
    Core --> R["streaming replication"]
    Core --> P["declarative partition"]
    Core --> E["extension 인터페이스"]

    E -.확장.-> Ext1["sharding
Citus / Multigres"]
    E -.확장.-> Ext2["암호화
pg_tde"]
    E -.확장.-> Ext3["hints
pg_hint_plan"]

    Proxy["외부 프로세스"] -.연결 앞단.-> Pool["pooler
PgBouncer"]

    App["애플리케이션"] --> Proxy
    Proxy --> Core

코어는 쿼리 처리, MVCC, streaming replication, declarative partition까지를 책임집니다. 그 위로 sharding, 암호화, hint 같은 빈칸은 extension이 메우고, connection pooling은 아예 별도 프로세스가 연결 앞단에서 받습니다. 이제 각 빈칸을 풀어씁니다.

빈칸 1. 내장 암호화

첫 번째 빈칸은 TDE입니다.

무엇이 없나

데이터 파일을 디스크에 암호화해 저장하는 Transparent Data Encryption(TDE)이 코어에 없습니다. 디스크나 백업 미디어를 통째로 탈취당해도 키 없이는 못 읽게 막는 data-at-rest 보호인데, Oracle/SQL Server는 오래전부터 내장한 기능입니다.

왜 코어에 없나

암호화 자체는 어렵지 않습니다. 어려운 건 키 관리와 성능, 그리고 WAL, 임시 파일, 통계까지 빠짐없이 덮는 일관성입니다. 코어에 넣으려면 KMS 연동 모델까지 표준화해야 하는데, 이 합의가 더딥니다. Momjian은 cluster file encryption을 단일 호스트 항목으로 분류하면서, 진행은 있되 코어 합의에는 이르지 못한 상태로 짚습니다.

지금은 무엇으로 메우나

Percona의 pg_tde extension이 2025년에 production 궤도에 올랐습니다. 2025년에 WAL 암호화가 GA에 도달했고, 2025년 11월에는 pg_tde 2.1이 릴리스되며 PostgreSQL 18.1과 asynchronous I/O까지 지원합니다. HashiCorp, Thales, Fortanix, OpenBao 같은 KMS 연동도 붙었습니다. pg_tde는 구독 뒤에 숨기지 않은 오픈소스라는 점을 내세웁니다. 한편 EDB도 TDE를 제공하지만, 이쪽은 EDB Postgres Advanced Server/Extended Server의 라이선스 제품에서만 쓸 수 있습니다.

pg_tde를 쓸 때 백업 도구와의 궁합은 따로 검증이 필요합니다. 이 주제는 암호화된 PostgreSQL은 pgBackRest로 백업될까 글에서 한 편 다뤘습니다.

코어 편입 전망

당장은 어렵습니다. pg_tde가 사실상의 오픈소스 표준 자리를 먼저 굳히는 중이고, 코어 편입은 그 다음 논의가 될 가능성이 큽니다.

빈칸 2. 내장 connection pooler

무엇이 없나

PostgreSQL은 17까지도 내장 connection pooler가 없습니다. PostgreSQL은 연결 하나당 프로세스 하나(process-per-connection) 모델이라, 연결 수가 늘면 메모리와 context switch 비용이 가파르게 오릅니다. 수천 개의 짧은 연결을 받는 웹 백엔드에서 특히 아픕니다.

왜 코어에 없나

프로세스 모델 자체가 발목을 잡습니다. 내장 pooler를 제대로 넣으려면 연결 처리 구조를 손봐야 하고, 이는 server-side threading 같은 더 깊은 과제와 얽힙니다. 패치 제안은 여러 번 올라왔지만 코어 합의까지 가지 못했습니다.

지금은 무엇으로 메우나

외부 프로세스가 연결 앞단에서 받습니다. 가장 널리 쓰이는 건 PgBouncer로, transaction/session 단위 풀링을 지원하는 경량 도구이자 사실상의 표준입니다. Pgpool-II는 풀링에 더해 load balancing/query routing까지 묶은 무거운 도구고, Supavisor는 Supabase가 Elixir로 만든 멀티테넌트 pooler로 클라우드 규모를 노립니다.

클라우드 사업자들은 이걸 관리형으로 흡수했습니다. Azure Database for PostgreSQL은 PgBouncer를 서버 단위 옵션으로 켤 수 있게 내장했습니다.

코어 편입 전망

논의는 살아 있습니다. 다만 process-per-connection 구조와 threading 과제가 함께 풀려야 본격적인 내장 pooler가 가능해집니다. 단기간에 PgBouncer를 대체할 그림은 아닙니다.

빈칸 3. optimizer hints

무엇이 없나

쿼리 planner에게 “이 인덱스를 써라”, “이 조인 순서로 가라” 식으로 강제하는 optimizer hint가 코어에 없었습니다. Oracle 사용자가 PostgreSQL로 옮길 때 가장 먼저 당황하는 지점 중 하나입니다.

왜 코어에 없나

PostgreSQL 커뮤니티는 hint를 의도적으로 거부해 왔습니다. planner가 통계로 최적해를 찾게 두는 편이 장기적으로 낫고, hint는 잘못된 플랜을 영구히 고착시키는 부채가 된다는 철학입니다. “hint가 필요하면 그건 planner나 통계를 고칠 신호"라는 입장이 오래 유지됐습니다.

지금은 무엇으로 메우나

pg_hint_plan extension이 그 자리를 메워 왔습니다. 주석 형태로 hint를 심어 planner 동작을 강제합니다.

코어 편입 전망

여기서 흐름이 바뀌었습니다. optimizer hint의 1차 형태가 PostgreSQL 19에 들어옵니다. 오래 거부하던 기능이 코어에 발을 들이는 사례라, 빈칸 목록에서 가장 먼저 지워질 항목입니다.

빈칸 4. 단일 호스트의 나머지 성능 항목

Momjian이 단일 호스트 묶음으로 짚은 나머지를 한 번에 정리합니다. 이들의 공통점은 기능 자체의 결핍이라기보다 더 빠르게 하기 위한 장치라는 점입니다.

columnar storage는 분석 워크로드용 열 지향 저장인데, 코어에 없고 Citus의 columnar나 Hydra 같은 extension이 메웁니다. 코어 작업은 아직 널리 알려진 움직임이 없습니다. global index는 partition 테이블 전체를 가로지르는 인덱스로, 여러 partition에 걸친 unique 보장을 한 인덱스로 처리하려는 것인데 지금은 코어에 없어 수동 우회에 의존합니다. direct I/O는 OS 페이지 캐시를 우회하는 I/O로, PostgreSQL 18이 asynchronous I/O(AIO) 서브시스템을 들이며 기반이 깔렸고 그 위에서 진행 중입니다. server-side threading은 프로세스 모델을 thread 모델로 바꾸는 장기 과제라 connection pooler 빈칸과 뿌리가 같습니다.

64-bit transaction ID는 조금 더 설명이 필요합니다. 32-bit XID는 wraparound 위험을 안고 삽니다. PostgreSQL은 epoch을 포함한 xid8 타입을 이미 갖췄지만, 내부 XID를 통째로 64-bit로 넓히는 작업은 on-disk 호환성 때문에 코어에 못 들어왔습니다. Postgres Pro fork는 내부 64-bit XID를 상용으로 돌리고 있어, 가능은 하되 코어 편입의 벽이 높다는 걸 보여줍니다.

빈칸 5. sharding

무엇이 없나

데이터를 여러 노드에 수평 분산하는 sharding이 코어에 없습니다. 단일 서버 용량을 넘어서는 순간 부딪히는 벽입니다. MySQL 진영은 Vitess라는 검증된 sharding 시스템을 오래 가졌지만, PostgreSQL은 비교 대상이 없었습니다.

왜 코어에 없나

sharding은 distributed transaction, 분산 plan, 노드 간 일관성까지 묶인 거대한 과제입니다. PostgreSQL은 declarative partition으로 단일 노드 안의 분할까지는 코어에 들였지만, 노드를 가로지르는 분산은 extension/미들웨어의 몫으로 남겨 뒀습니다.

지금은 무엇으로 메우나

Citus는 분산 PostgreSQL extension입니다. Microsoft가 인수해 Azure로 들어갔고, Azure의 Elastic Clusters가 이 오픈소스 기술 위에서 row/schema 단위 sharding을 제공합니다. Citus 14는 PostgreSQL 18을 지원합니다. Multigres는 2025년 6월 Supabase가 Vitess 공동 창시자 Sugu(수구)를 영입해 시작한 “PostgreSQL용 Vitess"입니다. PostgreSQL 앞단에 놓이는 proxy로 표준 PostgreSQL 호환을 최우선에 두며, Vitess와 같은 Apache 2.0 라이선스 오픈소스입니다.

Multigres는 분량이 커서 PostgreSQL에도 Vitess가 온다 글에서 따로 다뤘습니다.

코어 편입 전망

가까운 시일에는 어렵습니다. 코어가 분산 트랜잭션까지 흡수하기보다, Citus/Multigres 같은 미들웨어가 각자 자리를 잡는 그림이 현실적입니다.

빈칸 6. 다중 호스트의 나머지 항목

다중 호스트 묶음의 나머지를 정리합니다. multi-master replication은 여러 노드가 동시에 write를 받는 구성인데, 코어의 replication은 단일 primary 기준입니다. pgEdge의 Spock이 multi-master logical replication을 제공해 지리적으로 분산된 배치에 쓰이고, EDB의 BDR이 상용으로 그 자리를 채웁니다. Oracle RAC 동급은 공유 스토리지 위에서 여러 인스턴스가 같은 DB를 동시에 여는 RAC 모델을 말하는데, PostgreSQL에는 이에 직접 대응하는 코어 기능도, 널리 쓰이는 대체재도 사실상 없습니다. 빈칸 중 가장 비어 있는 자리입니다. DDL의 logical replication은 결이 조금 다릅니다. logical replication이 DML은 나르지만 CREATE TABLE 같은 DDL은 자동으로 나르지 못하는데, PostgreSQL 19에서 sequence 복제 같은 주변부가 채워지며 부분적으로 전진하고 있습니다.

왜 비어 있는가

빈칸들을 한 발 떨어져 보면 공통된 이유가 보입니다. 첫째는 철학입니다. 코어를 작게 두고 extension/외부 프로세스로 확장하는 노선인데, optimizer hint를 오래 거부한 것이 대표적입니다. 둘째는 구조입니다. process-per-connection 모델이 connection pooler와 threading을 동시에 막고, on-disk 포맷 호환성이 64-bit XID를 막습니다. 셋째는 합의 비용입니다. TDE의 키 관리나 sharding의 분산 트랜잭션처럼 표준화 합의가 비싼 과제는 코어 진입이 더딥니다.

그리고 Momjian의 결론처럼, 이 빈칸들은 대부분 “PostgreSQL이 못 하는 일"이라기보다 “더 빠르게/더 크게 하기 위한 장치"에 가깝습니다. 기능의 결핍보다는 성능과 규모의 천장에 걸리는 문제라, 대부분의 빈칸 옆에는 이미 그 천장을 뚫는 도구가 하나씩 서 있습니다.

닫으며

PostgreSQL의 빈칸 목록은 약점 목록이라기보다 지도에 가깝습니다. 어디까지가 코어이고 어디부터 extension/미들웨어의 영역인지, 그리고 다음 5년 동안 어느 칸이 먼저 채워질지를 보여줍니다. optimizer hint가 PostgreSQL 19에서 코어로 들어오는 것처럼, 빈칸은 고정된 게 아니라 천천히 메워집니다.

DBA 입장에서 실무적으로 남는 건 단순해요. 벽에 부딪히기 전에 어느 칸이 비어 있는지 미리 알아 두면 돼요. sharding이 필요하면 Citus나 Multigres를 일찍 검토하고, 연결 폭증이 보이면 PgBouncer를 처음부터 설계에 넣고, 규제 요건이 있으면 pg_tde를 미리 검증하면 돼요. 빈칸은 막다른 길이라기보다 무엇을 곁들여야 하는지 알려주는 표지판에 가깝습니다.

1차 출처

Momjian 발표:

• What’s Missing in Postgres? (슬라이드 PDF): Bruce Momjian, 2026-04
• Postgres Pending Features Presentations: Bruce Momjian
• Bruce Momjian: Postgres Blog

암호화(TDE):

• percona/pg_tde — GitHub
• pg_tde 2.1 released — Percona Docs, 2025-11-27
• Coming to PostgreSQL — on-disk database encryption — The Register, 2025-07-02

connection pooling:

• PgBouncer: 공식 사이트
• PgBouncer on Azure Database for PostgreSQL: Microsoft Learn

optimizer hints:

• PostgreSQL Optimizer Hints Discussion: DEV

sharding / multi-host:

• citusdata/citus: GitHub
• Announcing Multigres: Vitess for Postgres, Supabase, 2025-06
• What’s new with Postgres at Microsoft, 2026 edition: Microsoft Community Hub

64-bit XID:

• Add 64-bit XIDs into PostgreSQL 15: pgsql-hackers thread
• Transactions and Identifiers: PostgreSQL Documentation