PostgreSQL 부터

데이터를 저장할 도구를 고르는 일은 자주 부담입니다. NoSQL · 분산 SQL · 그래프 DB · 시계열 DB 가 줄지어 있습니다. 그러나 많은 프로젝트가 처음 한참 동안 PostgreSQL 한 가지로 충분합니다.

1. PostgreSQL 에 대한 이야기

PostgreSQL 의 뿌리는 1986 년 UC Berkeley 의 POSTGRES 연구 프로젝트(Michael Stonebraker 주도) 에 있습니다. SQL 인터페이스가 추가된 이후 1996 년 PostgreSQL 이라는 이름으로 오픈소스 커뮤니티에 이양됩니다. 라이선스는 BSD-like (PostgreSQL License) 라 상업·수정·재배포에 큰 제약이 없습니다.

PostgreSQL 의 정체성은 "확장 가능한 관계형 DBMS" 입니다. 타입·연산자·인덱스·언어를 모두 사용자 코드로 더할 수 있는 구조에서 출발했고, 이는 오늘날 extension 생태계로 이어집니다.

2. ACID 와 표준 SQL

PostgreSQL 은 트랜잭션의 원자성·일관성·격리성·지속성(ACID) 을 기본값으로 보장합니다. 단일 인스턴스 안에서 격리 수준은 Read Committed 가 기본이며 Repeatable Read · Serializable 까지 선택 가능합니다.

표준 SQL 준수도 단단합니다. CTE(WITH) · 윈도우 함수 · LATERAL 조인 · 재귀 쿼리 같은 표준 기능을 다른 RDBMS 보다 일찍 안정화한 사례가 많습니다. JSON 표준(SQL/JSON 경로 표현식) 도 점진적으로 도입됐습니다.

3. Extension 생태계

CREATE EXTENSION ... 한 줄로 새 기능을 끼워 넣을 수 있습니다.

extension 은 PostgreSQL 메이저 버전과 호환성이 묶여 있어 업그레이드 계획에 함께 포함시키는 편이 안전합니다.

4. MySQL · MariaDB 와의 비교

MySQL 은 1995 년 등장했고 LAMP 스택의 일부로 널리 퍼졌습니다. 2009 년 Oracle 이 Sun 을 인수하면서 MariaDB 가 포크됐습니다. 강점은 익숙함·튜닝 자료의 풍부함·일부 워크로드의 처리량입니다.

PostgreSQL 과의 차이로 자주 언급되는 항목들.

• 트랜잭션·격리 — InnoDB 기준 비슷하지만 기본값과 잠금 모델 세부가 다릅니다.
• DDL — MySQL 의 일부 DDL 은 묵시적 커밋을 일으킵니다. PostgreSQL 은 트랜잭션 안에서 DDL 을 묶기가 비교적 자연스럽습니다.
• 타입 풍부함 — PostgreSQL 이 배열·JSONB·범위·UUID·열거형·도메인 등에서 더 풍부합니다.
• 확장성 — PostgreSQL extension 모델이 더 깊습니다.

선택은 워크로드·운영 자원·생태계 친숙도에 좌우됩니다.

5. SQLite 와의 자리 차이

SQLite 는 D. Richard Hipp 이 2000 년에 만든 라이브러리형 DB 입니다. 별도 서버 없이 한 파일에 데이터를 담습니다. 임베디드·데스크탑·모바일·테스트 환경에서 강합니다. 동시 쓰기 다중 클라이언트는 약점이지만 단일 프로세스 읽기는 매우 빠른 편입니다.

예를 들어 한 프로젝트 의 food-app · language-app 가 SQLite 를 씁니다. 로컬 앱이라 서버가 필요 없고 사용자 PC 한 대 안에서 끝납니다.

6. CockroachDB · YugabyteDB

CockroachDB(2015 년 GA) 와 YugabyteDB(2018 GA) 는 PostgreSQL 호환을 표방하는 분산 SQL 후보입니다. 글로벌 분산·자동 샤딩·강한 일관성을 내세웁니다. PostgreSQL 와이어 프로토콜·SQL 일부를 따라가지만 구현은 별개 엔진이라 PostgreSQL 만의 기능 (특히 일부 extension) 이 그대로 쓰이지는 않습니다.

7. MongoDB 와의 비교

MongoDB 는 2009 년 등장한 문서 지향 DB 입니다. JSON 유사 BSON 문서를 컬렉션에 저장합니다. 스키마 자유와 빠른 초기 개발이 강점으로 자주 언급되지만 트랜잭션·조인·집계의 풍부함에서는 관계형 DB 와 다른 자리에 섭니다.

PostgreSQL 의 JSONB 가 도입된 이후 "JSON 이 필요해서 MongoDB 를 골랐다" 는 명분이 줄었다는 의견도 자주 보입니다.

8. PostgreSQL for everything

근래 들어 "처음에는 PostgreSQL 한 가지로 시작하라" 는 권고가 자주 보입니다.

• 큐: 별도 메시지 브로커 대신 SELECT ... FOR UPDATE SKIP LOCKED 로 작업 큐 (river · graphile-worker · pgmq).
• 검색: pg_trgm · tsvector 풀텍스트 인덱스로 작은~중간 검색 요구를 충족.
• 벡터: pgvector extension 으로 임베딩 저장·유사도 검색.
• 시계열: timescaledb 또는 BRIN 인덱스 + 파티셔닝.
• 캐시: 마테리얼라이즈드 뷰 또는 캐시 테이블.

장점은 운영 표면이 하나라는 점입니다. 백업·모니터링·인증·접근 제어를 한 곳에서 다룹니다. 한계는 한 DB 가 너무 많은 일을 맡으면 단일 장애점이 커지고, 워크로드가 갈라지면 결국 분리해야 한다는 점입니다.

9. 자주 걸리는 자리

메이저 버전 업그레이드 — extension 호환성 확인이 필수입니다. pg_upgrade 또는 논리적 복제로 다운타임을 줄일 수 있습니다.

인코딩·로케일 고정 — DB 생성 시점의 LC_COLLATE 가 정렬에 영향을 줍니다. 운영 중간에 바꾸기 어려우니 처음에 결정합니다.

autovacuum 비활성화 — 끄면 bloat 가 누적됩니다 (postgres-deep 에서 자세히 다룹니다).

시퀀스 캐시 — nextval 의 캐시 설정이 다중 프로세스에서 갭을 만들 수 있습니다.

타임존 가정 — TIMESTAMPTZ 와 TIMESTAMP 는 미묘하게 다릅니다. 저장은 UTC, 표시 시 변환이 일반적입니다.

하고픈 말

데이터 저장소 선택은 처음에 무겁게 느껴지지만 PostgreSQL 한 가지로 멀리 갑니다. 분리의 시점은 워크로드·트래픽·SLA 가 결정해 주지 도구 카탈로그가 결정해 주지 않습니다.

Next

• postgres-deep

PostgreSQL 공식 문서 · PostgreSQL 라이선스 · Awesome Postgres · PostgreSQL 위키 — History 를 참고합니다.