Postgres 활용 방법

 (github.com/Olshansk)
8P by GN⁺ | ★ favorite | 댓글 1개
  • 이 저장소는 “Keep It Simple Stupid, just use postgres”라는 방향 아래, Postgres를 다양한 용도에 활용하는 도구와 사례를 모아 보여줌
  • 목록은 Amazing CTO의 Postgres for Everything 글과 @cpursley의 GitHub gist에서 영감을 받았으며, Postgres 위에 새 도구나 활용 방식이 계속 나온다는 이유로 유지됨
  • 범위는 cron 작업, 임베디드 Postgres, 메시지 큐, 분석, GIS, 감사 로그, 접근 제어, 검색, 시계열, NoSQL, 그래프, HTTP, API, CDC, 캐싱, 테스트, 마이그레이션, 성능 튜닝, 모니터링, 확장, UI, CLI, 시각화, 패키지 관리, 보안, 금융 원장까지 넓음
  • 각 항목은 Postgres 확장, 라이브러리, API 플랫폼, 글, 도구를 링크 중심으로 정리하며, 일부는 DuckDB, pgvector, PostGIS, PgBouncer, GraphQL, CDC 같은 구체 기술과 연결됨
  • 특정 코드 조각, 도구, 프로젝트를 예시로 추가하려는 사용자는 링크와 함께 PR을 열고, 새 pull request template을 사용해야 함

저장소의 목적과 유지 방식

  • Postgres for Everything 저장소의 목표는 Postgres를 여러 용도에 쓰는 방법을 보여주는 것임
  • 저장소는 다음 자료에서 영감을 받음
  • Postgres 위에 새 도구가 나오거나 새로운 활용 방식이 계속 생기기 때문에, 이를 추적하는 장소로 유지됨
  • 다른 예시가 있으면 PR을 제출할 수 있음
  • 코드 조각, 도구, 프로젝트를 보여주려면 링크와 함께 PR을 열고 pull request template을 사용해야 함

읽을거리와 사례 글

작업 실행, 임베딩, 큐

  • Cron Jobs

  • Embeddable Postgres

    • PGLite: 브라우저, Node.js, Bun, Deno에서 실행 가능한 10MB 미만의 WASM Postgres 빌드를 TypeScript 라이브러리로 패키징함
    • pgmicro: SQLite 호환 스토리지 엔진 기반의 in-process PostgreSQL 재구현

  • Message Queues

분석, 지도, 감사, 권한

검색, 시계열, 컬럼형, NoSQL, 그래프

외부 데이터, HTTP, API, GraphQL, CDC

캐싱, 테스트, 애플리케이션, 마이그레이션

성능, 모니터링, 확장, UI

  • Performance Tuning

  • Monitoring

    • StatsMgr: WAL, SLRU, checkpointing 등 통계 관리를 지원
    • pgMonitor: Prometheus, Grafana, SQL Exporter, pgMonitor 확장으로 메트릭을 시각화하는 모니터링 솔루션

  • Testing

    • regresql: PostgreSQL을 지원하는 SQL 쿼리 회귀 테스트 도구

  • Scaling & Storage

    • Snowflake-Labs/pg_lake: Postgres를 독립형 lakehouse 시스템으로 활용하고, S3 같은 객체 저장소의 Iceberg 테이블에 대해 트랜잭션과 쿼리를 지원
    • pgdogdev/pgdog: PostgreSQL 샤딩이 가능한 트랜잭션 풀러와 논리 복제 관리자
    • pgbouncer/pgbouncer: PostgreSQL용 경량 연결 풀러
    • orioledb.com: 온디스크와 인메모리 엔진의 장점을 결합하는 PostgreSQL 확장

  • User Interfaces & Dashboards

개발자 도구, 시각화, 패키지, 보안, 금융

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 100명 이상 엔지니어 규모로 커질 때 Postgres DB 하나를 모든 것에 쓰지는 않는 게 좋음
    결국 데이터베이스가 API가 되는 상황을 피하기 어렵다
    논리적·물리적 경계를 잘 나누고 각 단위가 자기 Postgres를 갖도록 확장할 기술 리더십이 있다면 “Postgres for everything”도 탄탄한 선택임
    다만 그런 어려운 일을 해내는 CTO는 생각보다 드물었음

    • 너무 일찍부터 계획할 필요는 없음
      대부분의 회사는 엔지니어 100명 이상까지 가지 못하니, 일단 출시하고 이런 걱정은 훨씬 나중에 해도 됨
      실제 사용자는 2명도 없고 과로한 엔지니어 1명뿐인데, 서버 40대를 두고 백만 명의 엔지니어와 수십억 방문자를 가정한 구조로 짜인 회사를 보면 과설계가 삶을 어렵게 만든다는 걸 느낌
    • “성공한”에 따옴표를 붙일 필요는 없음
      이 사람들은 실제로 제품을 출시했음
      여러 데이터베이스로 마이그레이션하고 사용자 정보를 동기화하는 일은 단계적 이정표이지, 매 순간 필요한 전제는 아님
    • “데이터베이스가 API가 된다”는 게 오히려 Postgres for everything의 요지 아닌가 싶음
    • Database-as-the-API도 꽤 멀리까지 확장 가능함
      특히 고객마다 단일 테넌트 샤드를 팔고, 결과적으로 고객마다 별도 데이터베이스를 주는 구조라면 더 그렇다
      제품이 아직 도메인과 팔릴 기능을 모르는 시점에 논리적 소프트웨어 경계를 먼저 긋는 건 꽤 위험함
    • 저장 프로시저와 뷰로 제대로 추상화했다면 데이터베이스를 API로 쓰는 방식도 잘 동작함
      GraphQL로 노출된 서비스 100개보다 훨씬 덜 취약할 수도 있음

  • Postgres를 정말 좋아하지만, 팀 밖 사람들에게 데이터베이스에서 생성한 API를 그대로 노출하는 건 피해야 함
    이렇게 하면 데이터를 저장하는 방식을 바꾸기가 크게 제한됨
    예전에 이 주제로 글을 썼고, 지금도 생각은 크게 바뀌지 않았음
    이런 강한 결합은 원치 않을 것임: https://wundergraph.com/blog/six-year-graphql-recap#generate...

    • 강한 결합이 정확히 뭐가 문제인지 궁금함
      나중에 데이터베이스 컬럼명을 바꿔도 API를 안 바꾸려고, 형식 A를 형식 B로 번역하는 계층 전체를 하나 더 넣겠다는 건가 싶음
    • 중간 계층으로 뷰를 쓰면 되지 않나 싶음

  • 최근 Postgres 인덱스가 건너뛰기 스캔을 지원하지 않는다는 걸 알고 짜증났음
    문자열에 널 문자 \u0000도 넣을 수 없음
    훌륭한 DB지만 곳곳에 이상한 빈틈이 있음
    https://wiki.postgresql.org/wiki/Loose_indexscan
    https://stackoverflow.com/questions/28813409/are-null-bytes-...

    • 문자열 안에 널 문자를 넣을 합리적인 용도가 뭐가 있을지 궁금함
      처음 드는 생각은, 널이 들어간 문자열은 당연히 거부해야 한다는 쪽임
    • 널 문자가 필요하다면 blob을 소개하고 싶음
    • 맞음, 지금은 건너뛰기 인덱스 스캔에 사용자 정의 SQL이 필요함
      캐시 비슷한 용도가 일급 기능이 아닌 것도 좀 아쉬움
      비로그 테이블도 꽤 쓸 만하고 임시 테이블도 좋지만, 전반적으로 번거롭고 어색하며 실제로 필요한 것과는 다르게 느껴짐

  • PGQueuer는 PostgreSQL만으로 만든 Python용 경량 작업 큐임
    효율적이고 안전한 작업 처리를 위해 SKIP LOCKED를 쓰고, 단순하면서도 성능을 유지하는 최소 설계를 택함
    이미 Postgres를 쓰고 있고 추가 인프라 없이 Python 친화적인 방식으로 백그라운드 작업을 관리하고 싶다면 볼 만함: GitHub - https://github.com/janbjorge/pgqueuer

    • 또 다른 초기 Python 선택지로 https://github.com/TkTech/chancy도 있음
      이쪽은 반대로 대시보드, 워크플로, 혼합 모드 워커 같은 기능을 포함하려는 방향임
      문서의 비슷한 프로젝트 섹션을 보면 Postgres 기반 작업 큐가 많이 나옴
    • SKIP LOCKED가 정말 그렇게 효율적이라는 주장에는 늘 의문이 있었음
      아주 짧은 작업과 오래 걸리는 작업이 섞여 있으면, 긴 작업 하나가 끝나는 동안 짧은 작업 수백·수천 개가 실행될 수 있음
      그 경우 긴 작업 행들은 계속 잠겨 있어 작업 테이블에서 수백 번씩 건너뛰어짐
      동시에 오래 도는 작업이 많을수록 잠긴 행을 반복해서 건너뛰는 낭비가 커지므로, 부하가 낮을 때는 괜찮아도 별도의 “실행 중” 테이블로 옮기는 구조가 더 효율적일 수 있음
    • 전용 작업 큐 시스템과 비교했을 때 장점이 무엇인지 궁금함

  • 일부 프로젝트에서 MariaDB/MySQL에 묶여 있다 보니 최근 PostgreSQL과 비교해 봤는데, JSON, 시스템 버전 관리가 붙은 임시 테이블, 컬럼형·벡터 저장소 같은 확장 기능이 거기에도 많이 있었음
    LISTEN/NOTIFY 같은 기능은 빠져 있는 편이지만, 전반적으로 꽤 따라오고 있다는 점이 놀라웠음
    다만 많은 레거시 앱에서는 이런 기능이 거의 쓰이지 않을 것 같음

  • 이 홍보도 추가해 주면 좋겠음: https://github.com/jankovicsandras/plpgsql_bm25
    Rust 확장을 쓸 수 없는 환경 등을 위한 PL/pgSQL 기반 오픈소스 BM25 검색이고, pgvector와 Reciprocal Rank Fusion을 이용한 하이브리드 검색도 지원함

  • “Amazing CTO의 이 글에서 영감을 받았다”는 문구를 아침에 보고, 내 글이 참조된 걸 발견하니 기분이 최고였음
    https://www.amazingcto.com/postgres-for-everything/

    • “Elastic 대신 Postgres로 전문 검색을 쓰라”는 제안은 별로임
      Postgres 전문 검색은 매우 제한적이고 사용자 친화적이지 않음

  • 여러 기능에 접근하는 API 하나가 있으면 장점이 많아 보임
    예를 들어 메시지 큐와 통합하는 대신 INSERT만 하면 되는 건 마찰을 크게 줄여 줌
    벡터 검색도 당연히 이해됨
    하나로 다 할 수 있는데 데이터베이스를 두 개 둘 이유가 없음
    다만 Postgres로 HTML을 생성하는 건 의문임
    직접 해보진 않았지만 사용자 인터페이스를 만드는 현실적인 방식이라고는 상상하기 어려움

  • Postgres 데이터베이스를 자가 호스팅하는 좋은 자료가 있는지 궁금함
    여러 개인 프로젝트용 DB 서버를 직접 운영하려고 하는데, 백업·최적화·Docker 사용 여부 같은 팁과 모범 사례를 잘 알고 싶음

    • 이 YouTube 채널에는 일반 Linux 머신에 Postgres를 설치하고, 설정하고, 고가용성으로 동작하게 만드는 방법을 설명하는 영상이 많음
      생각보다 쉬움
      https://youtube.com/playlist?list=PLBrWqg4Ny6vVwwrxjgEtJgdre...
    • 직접 호스팅할 때는 단순하다는 이유로 SQLite 쪽에 기움
      제자리 업그레이드, Litestream을 통한 간단한 백업 등이 쉬움
      Postgres 주 버전 업그레이드가 직접 호스팅하지 않는 주된 이유인데, 다시 생각해 봐야 할지도 모르겠음
    • 백업은 시작 단계라면 pg_dump가 좋고 단순함
      튜닝에는 postgresqlco.nf가 훌륭함
      https://postgresqlco.nf/tuning-guide
    • 찾던 답은 아니겠지만, 비슷한 이유로 최근 서비스를 알아봤음
      작은 MVP 프로젝트들을 계속 배포하고 싶은데 Render에서 프로젝트마다 DB 서비스 하나씩 비용을 내고 싶지는 않았음
      https://www.thenile.dev/pricing는 무제한 데이터베이스를 지원하는 것 같음
    • 온프레미스라면 컨테이너를 쓰되 데이터 폴더는 마운트된 볼륨으로 두는 게 좋음
      클라우드나 Kubernetes에서는 그냥 관리형 DB를 쓰는 편이 낫고, Kubernetes에서 DB를 직접 세팅하는 건 파일시스템 때문에 어렵다고 알고 있음

  • 그래프 데이터를 위해 Apache Age를 통합하느라 거의 2주를 썼는데, 프로젝트가 정체되고 엉망이라는 걸 깨달았음
    이런 목록을 곧이곧대로 믿으면 안 됨
    이제 DGraph에서 더 나은 결과를 기대하고 있지만, 그래프 데이터베이스들은 불안정한 생태계 위에 있는 것처럼 보임

    • 그래프 데이터베이스가 잘 맞는 용도가 어떤 건지 궁금함
      몇 가지는 있을 것 같지만 잘 떠오르지 않고, 오히려 맞지 않는 곳에 그래프 DB가 쓰인 경우를 본 적은 있음
    • Dgraph에는 어떤 함정이 있는지 궁금함
      Neo4j 대신 선택하지 않을 이유가 뭘까?
      참여했던 그래프 DB 프로젝트들은 전부 Neo4j를 썼는데, 좋은 대안이 있다면 알고 싶음
    • Apache Age도 같은 상황이었음
      조금 더 자세히 들려줄 수 있으면 좋겠음
    • 나도 이 말을 하러 왔음
      마지막으로 확인했을 때 Apache Age는 Neo4j보다 훨씬 떨어졌음
      기술적으로 존재하긴 하고 목록에 들어갈 권리도 있지만, 진지한 작업 부하에는 추천하지 않음
답변달기