PostgreSQL이면 충분하다

새 사이트 보기: https://postgresisenough.dev

• 단순화하기: 코드를 데이터베이스 함수로 옮기기

• 그냥 모든 것에 Postgres를 쓰세요

• 그냥 Postgres를 쓰세요

• PostgreSQL은 세계 최고의 데이터베이스입니다

• Postgres가 데이터베이스 세계를 먹어치우고 있습니다

• Hacker News 토론

백그라운드 작업과 Cron Jobs

• https://github.com/citusdata/pg_cron

• https://github.com/cybertec-postgresql/pg_timetable

• https://github.com/crunchydata/pg_incremental

메시지 큐

• https://adriano.fyi/posts/2023-09-24-choose-postgres-queue-technology

• https://github.com/tembo-io/pgmq

GIS/매핑

• https://github.com/postgis/postgis

감사 로그

• https://github.com/arkhipov/temporal_tables

• https://github.com/supabase/supa_audit

• https://github.com/pgMemento/pgMemento

• https://github.com/pgaudit/pgaudit

접근 제어와 권한 부여

• https://github.com/arkhipov/acl

• https://www.postgresql.org/docs/current/pgcrypto.html

• https://github.com/michelp/pgjwt

• https://supabase.com/docs/guides/database/vault

검색

• https://github.com/pgvector/pgvector

• Vecto: Postgres(pgvector)와 Elixir(Ecto)로 구현하는 하이브리드 검색

• Postgres 전문 검색 (유용한 링크 모음)

• https://github.com/paradedb/paradedb

• https://github.com/postgresml

시계열

• https://github.com/timescale/timescaledb

컬럼 지향

• https://github.com/paradedb/paradedb/tree/dev/pg_analytics

• https://github.com/paradedb/paradedb/tree/dev/pg_lakehouse

• https://github.com/hydradatabase/hydra

• https://github.com/citusdata/cstore_fdw

NoSQL

• https://github.com/microsoft/documentdb

• https://www.ferretdb.com

• https://github.com/event-driven-io/Pongo

• https://www.postgresql.org/docs/current/datatype-json.html

• https://github.com/robconery/dox

그래프 데이터

• https://age.apache.org

• https://github.com/edgedb/edgedb

외부 데이터

• https://github.com/supabase/wrappers

사용자 정의 타입

• pgPDF: Postgres용 pdf 타입

대체 쿼리 언어

• https://github.com/kaspermarstal/plprql

• https://supabase.github.io/pg_graphql

HTTP

• https://github.com/pramsey/pgsql-http

• https://github.com/supabase/pg_net

API

• https://github.com/PostgREST/postgrest

• https://github.com/hasura/graphql-engine

• https://postgraphile.org

• https://supabase.github.io/pg_graphql

이벤트, 복제, CDC

• https://www.postgresql.org/docs/current/sql-notify.html

• https://github.com/cpursley/walex (Postgres WAL 이벤트 구독 - Appraisal Inbox를 구동)

• https://github.com/PeerDB-io/peerdb

• https://github.com/debezium/debezium

• https://github.com/2ndQuadrant/pglogical

캐싱

• https://martinheinz.dev/blog/105

• https://github.com/readysettech/readyset

단위 테스트

• https://github.com/theory/pgtap

• https://github.com/peterldowns/pgtestdb

HTML과 애플리케이션

• SQLpage

• Omnigres

• pg_render

• plmustache

그래픽/비주얼

• pgSVG

마이그레이션

• https://github.com/purcell/postgresql-migrations

• https://www.bytebase.com/

• https://github.com/xataio/pgroll

• https://github.com/stripe/pg-schema-diff

성능 튜닝

• https://github.com/nexsol-technologies/pgassistant

• Index Advisor

• Dexter

• HypoPG

• pg_hint_plan

• PGHero

• https://codeberg.org/Data-Bene/StatsMgr

확장

• Cloudflare가 PostgreSQL 클러스터 15개만으로 초당 5,500만 요청을 처리한 방법

• https://github.com/supabase/supavisor

• https://github.com/postgresml/pgcat

• https://www.pgbouncer.org/

• https://github.com/pg-sharding/spqr

대시보드/UI

• Baserow

• NocoDB

• AppSmith

데이터 시각화

• Evidence

• Metabase

패키지 관리

• https://github.com/pgxman/pgxman

• https://github.com/supabase/dbdev

언어 서버

• https://github.com/supabase/postgres_lsp

브라우저 내부 및 WASM

• https://github.com/electric-sql/pglite

• https://github.com/instantdb/instant

기타

• Postgres 도구를 매우 폭넓게 정리한 목록

빠진 것이 있나요? 댓글로 공유하거나 PR을 보내 주세요: https://github.com/agoodway/postgresisenough

^{source https://gist.github.com/cpursley/c8fb81fe8a7e5df038158bdfe0f06dbb}

HN에서는 PostgreSQL의 활용 범위를 넓게 보자는 주장 자체보다, “충분하다”는 말을 어떻게 해석하냐를 두고 판단이 갈렸다. 많은 댓글은 PostgreSQL을 기본 선택지로 두는 데 동의했다. 특히 초기 제품이나 사용자가 많지 않은 서비스에서 검색, 작업 큐, 지리 정보, 단순 분석까지 별도 시스템을 먼저 붙이는 것은 운영 복잡도를 키운다는 시각이 강했다.

다만 반론은 명확했다. 관계형 데이터베이스는 영속 데이터를 다루는 도구이지, 애플리케이션 프레임워크나 대규모 메시징 시스템이 아니라는 지적이다. 비즈니스 로직을 데이터베이스 함수 안으로 밀어 넣는 방식에는 거부감이 컸다. 컨테이너나 함수, VM처럼 교체와 롤백이 쉬운 실행 환경과 달리 데이터베이스는 복구 부담이 크고, 한번 결합되면 나중에 떼어내기 어렵다는 실무 경험이 깔려 있다.

메시지 큐 논쟁도 같은 맥락이다. 일부는 SQS나 전용 큐를 쓰는 편이 단순하고 예측 가능하다고 봤다. 큐는 일반 데이터와 접근 패턴이 다르고, 테이블 팽창이나 autovacuum, 파티셔닝 문제를 일찍 만나게 할 수 있다는 이유다. 반면 작업 자체가 데이터 모델의 일부이거나 트랜잭션 일관성이 중요하다면 PostgreSQL 안에 두는 편이 낫다는 반박도 있었다. 실제로 오래 운영한 사례를 들어 충분히 감당 가능하다는 경험도 제시됐다.

결국 핵심은 기술 선호가 아니라 전환 비용과 운영 비용의 균형이다. Kafka, Elasticsearch, Snowflake 같은 도구는 운영 부담이 작지 않으므로 필요가 분명할 때 선택해야 한다는 데에는 공감대가 있었다. 동시에 시계열 대량 데이터, 고부하 큐, 검색 전문 기능처럼 요구사항이 선명한 영역에서는 처음부터 전용 도구가 더 이해하기 쉬울 수 있다.

선택 기준은 단순하다. PostgreSQL로 시작할 수 있는 문제인지, 장애 복구와 디버깅을 감당할 수 있는지, 나중에 분리할 경계가 보이는지를 먼저 확인해야 한다. “하나로 충분하다”는 말은 아키텍처를 단순하게 유지하자는 원칙으로는 유효하지만, 모든 책임을 데이터베이스에 모아도 된다는 기준은 아니다.