자, Postgres를 직접 호스팅해 보세요
(pierce.dev)- Postgres 자가 호스팅은 복잡하거나 위험하지 않으며, 관리형 서비스보다 저렴하고 성능 조정이 자유로운 방식임
- 대부분의 클라우드 데이터베이스 서비스는 오픈소스 Postgres를 약간 수정한 형태로 운영되며, 실질적 차이는 운영 자동화 수준에 있음
- 실제 운영 사례에서 자가 호스팅 Postgres는 수천 명의 사용자와 수천만 건의 쿼리를 안정적으로 처리하며, 유지보수 시간도 매우 적음
- AWS RDS 등 관리형 서비스의 가격 상승으로 인해, 동일 비용으로 훨씬 높은 사양의 서버를 직접 운영할 수 있음
- 인프라 관리가 복잡하지 않은 중간 규모 팀에게 자가 호스팅이 비용 효율성과 성능 면에서 현실적 대안이 됨
클라우드 중심 서사의 변화
- 과거에는 대부분의 기업이 자체 서버에서 데이터베이스를 직접 운영했으며, 이는 네트워크 지연이 적고 빠른 구조였음
- 1980~2000년대에는 애플리케이션 서버와 데이터베이스 서버가 같은 물리 장비에 위치하는 경우가 많았음
-
Amazon RDS(2009) 출시는 백업, 패치, 모니터링을 자동화해주는 매력적인 제안으로 받아들여졌음
- 초기에는 전용 서버와 비슷한 가격으로 운영 부담을 줄일 수 있었음
- 2015년 이후 클라우드 도입이 가속화되면서, 직접 인프라를 관리하는 행위가 비효율적이라는 인식이 확산됨
- AWS가 인프라를 대신 관리하고, 개발자는 애플리케이션 로직에 집중하는 구조가 표준으로 자리잡음
- 2025년 현재 RDS 가격이 크게 상승하며, 동일 비용으로 훨씬 높은 사양의 전용 서버를 임대할 수 있는 상황이 됨
- 예: db.r6g.xlarge 인스턴스(4 vCPU, 32GB RAM)는 월 $328로, 32코어·256GB RAM 서버 임대가 가능
관리형 서비스의 실제 구성
-
AWS RDS는 기본적으로 표준 Postgres에 AWS 전용 모니터링과 백업 시스템을 추가한 형태임
- EBS 스냅샷 기반 백업, Chef/Puppet/Ansible을 통한 구성 관리, PgBouncer 연결 풀링, CloudWatch 모니터링, 자동 장애 조치 스크립트 포함
- 이러한 구성은 기술적으로 복잡하지 않으며, 운영 자동화와 초기 배포 편의성이 핵심 가치임
- 동일 사양의 서버로 RDS에서 자가 호스팅으로 마이그레이션한 결과, 성능은 동일하거나 오히려 향상됨
- RDS에서 제한된 파라미터를 직접 조정할 수 있게 되어 성능 최적화 가능
자가 호스팅의 운영 복잡도
- DigitalOcean의 16 vCPU / 32GB RAM / 400GB 디스크 서버로 마이그레이션에 약 4시간이 소요되었으며, 이후 안정적 운영 확인
- 고가용성 제품군은 월 30분 정도의 관리 시간이 필요하며, 트래픽이 적은 서비스는 완전 자동화 가능
- 정기 관리 주기
- 주간(10분) : 백업 검증, 느린 쿼리 로그 검토, 디스크 용량 확인
- 월간(30분) : 보안 업데이트, 백업 보존 정책 점검, 용량 계획
- 분기별(2시간) : 모니터링 대시보드 갱신, 설정 최적화, 복구 테스트
- 장애 대응은 직접 책임이지만, RDS도 장애가 발생하며 결국 개발자가 대응해야 함
- 직접 운영 시 업데이트 시점과 위험 구간을 스스로 조정 가능, 안정성 확보 용이
자가 호스팅이 부적합한 경우
- 초기 개발자가 빠르게 프로토타입을 만들 때는 관리형 서비스가 더 간편함
- 대규모 기업은 전담 데이터베이스 엔지니어를 두거나, 인건비 절감을 위해 클라우드에 위탁하는 것이 효율적일 수 있음
- 규제 산업(PCI-DSS, HIPAA 등) 은 인증된 관리형 플랫폼 사용이 요구될 수 있음
주요 설정 포인트
-
메모리 설정: 하드웨어에 맞게
shared_buffers,effective_cache_size,work_mem,maintenance_work_mem등을 조정해야 함- 예:
shared_buffers는 RAM의 25%,effective_cache_size는 75% 설정
- 예:
-
연결 관리:
pgbouncer를 사용해 연결 풀링 구성, Python asyncio 환경에서 효율적 동작-
max_connections = 200,log_connections = on등 기본 설정 예시 제공
-
-
스토리지 튜닝: NVMe SSD 환경에서는
random_page_cost = 1.1,effective_io_concurrency = 200등으로 조정- 무작위 읽기 속도가 향상되어 쿼리 계획 최적화
-
WAL 설정: 내구성과 성능을 위한
wal_level = replica,max_wal_size = 2GB,checkpoint_completion_target = 0.9등 조정
결론
- 모든 인프라를 직접 운영할 필요는 없지만, Postgres는 자가 호스팅이 합리적인 영역에 속함
- 월 $200 이상을 RDS에 지출 중이라면, 비핵심 데이터베이스를 테스트 서버로 이전해볼 가치 있음
- 향후 인프라는 관리형 서비스와 자가 호스팅이 혼합된 하이브리드 형태로 발전할 가능성
- Postgres는 비용 대비 효율이 높은 자가 호스팅 후보로 평가됨
Hacker News 의견들
-
나는 self-hosting을 책임의 문제로 봄
SaaS 제품 몇 개를 직접 호스팅 중인데, AWS보다 훨씬 저렴하면서도 성능이 훨씬 좋음
다만 클라이언트 프로젝트에서는 AWS 비용을 지불하도록 설득함. 하드웨어 가용성 책임을 다른 쪽으로 넘길 수 있기 때문임
예산이 제한된 경우엔 RDS 비용이 부담스러움. Hetzner의 3노드 Galera 클러스터를 몇 달러로 운영하는 게 훨씬 경제적임
하지만 Cloudflare나 SQS 같은 관리형 서비스도 종종 장애가 발생함. 결국 완벽한 안정성은 어디에도 없음- “왜 NoNameCMS에서 Salesforce로 바꾸나요?”라고 물었더니, “Salesforce가 다운되면 WSJ에 기사 나니까”라는 답을 들음. 책임 전가의 현실적인 이유임
- 클라이언트의 고객 입장에서는 “Ikea랑 Disney도 다운됐다”는 말이 통하지 않음. 결국 자기 서비스가 멈췄다는 게 전부임
-
AWS Serverless PG가 있는데 굳이 직접 관리할 이유가 없음. 저트래픽 환경에서는 거의 무료 수준이고, 보안·백업·통합성 면에서 훨씬 우수함
AWS Aurora Serverless - VM 수준까지만 외주화하고 나머지는 직접 관리하는 절충도 가능함. 기술 스택의 운영 오버헤드에 따라 달라짐
- 20년간 수많은 클라이언트의 self-hosted SQL을 운영했는데, SQL 서버가 다운된 적은 한 번도 없음
클라우드 SQL은 오히려 비용 구조가 복잡하고, 백업 설정만 한 번 해두면 끝임
-
나는 self-hosting이 대부분에게 맞는 선택이라는 주장에 동의하지 않음
오히려 예산이 빠듯하거나, 혹은 전담 엔지니어를 둘 만큼 큰 규모일 때만 직접 호스팅이 합리적이라 생각함
소규모 기업은 클라우드에 맡기는 게 현실적임. 셋업 후 월 30~120분 관리면 충분하다는 계산이 나옴- 대부분의 회사는 클라우드를 써도 여전히 인프라 엔지니어를 고용함. “클라우드가 인건비를 줄인다”는 건 거짓임
Heroku나 Render 같은 PaaS는 일반 개발자도 다룰 수 있지만 훨씬 비쌈
결국 애플리케이션 복구 자동화가 안 되어 있으면 새벽 3시에 깨는 건 똑같음 - 대부분의 서비스는 고가용성이 필요하지 않음. 토요일에 다운돼도 월요일에 고치면 됨
내부 툴이라면 Docker에 Postgres 하나 추가하는 데 5분이면 충분함 - 클라우드도 월 1~2시간 정도는 관리 시간이 들어감. self-hosting과 큰 차이 없음
- RDS를 쓰면 오히려 가시성과 제어권이 떨어져서 디버깅이 더 어려움
- 논점은 효율이 아니라 문제가 생겼을 때 누가 욕을 먹느냐임. 클라우드면 책임을 돌리기 쉬움
- 대부분의 회사는 클라우드를 써도 여전히 인프라 엔지니어를 고용함. “클라우드가 인건비를 줄인다”는 건 거짓임
-
‘관리형 데이터베이스’의 정의가 혼란스러움
나에게 기본 요건은 자동 백업, 인덱스 최적화, 멀티데이터센터 장애조치, 포인트인타임 복구, 슬로우쿼리 분석, 스토리지 예측임
이런 걸 월 요금으로 제공한다면 self-hosting 논쟁은 의미가 없어짐- 문제는 전문 인력을 고용해야 한다는 점임. Postgres 담당자가 휴가 가면 버스 팩터 문제가 생김
결국 두 명을 두게 되고, 일이 심심하니 불필요한 개선을 시도하다가 6개월을 날리는 경우도 있음 - self-hosting의 이유는 결국 지연시간(latency) 임. 백업이나 분석은 기본이고, 직접 구축해야 가장 빠름
- 셋업만 잘 하면 백업이나 멀티리전 장애조치도 자동화 가능함
- 새벽 3시에 전화 안 올 서비스만 self-hosting함. 로그나 내부 분석용은 괜찮지만, DB는 절대 아님
- Yugabyte 오픈소스가 이런 기능 대부분을 커버함
- 문제는 전문 인력을 고용해야 한다는 점임. Postgres 담당자가 휴가 가면 버스 팩터 문제가 생김
-
관리형 DB가 VPS 대비 너무 비쌈
편의성 프리미엄을 기대했지만 실제로는 몇 배나 더 비쌈. 그래서 큰 프로젝트 외엔 쓰지 않음- 스스로 못한다고 믿게 만들고, 그 사이에 가격을 계속 올림. 옮길 기술이 없으니 종속됨
-
글에서 언급된 고가용성(HA) 부분이 부족함. WAL 설정만으로는 설명이 안 됨. 복제는 비용이 큼
-
Postgres가 HN에서 과대평가된 이유를 모르겠음
MongoDB처럼 자동 장애조치가 되는 HA 클러스터를 쉽게 구성할 방법이 없음. 실서비스에서는 어떻게 해결하는지 궁금함- PostgreSQL 커뮤니티도 이 문제를 인식하고 있음. MongoDB의 내장 복제 안정성을 부러워함
관련 논의: PostgreSQL 메일링리스트 - Kubernetes를 쓴다면 CloudNativePG가 사실상 표준 HA 솔루션임
- SQL 진영은 진짜 HA 대신 빠른 복구(Disaster Recovery) 에 익숙함
실제로는 모든 연결이 끊기고, 캐시가 초기화되며, 업그레이드 시엔 서비스 중단이 필수임
Oracle RAC만이 예외이고, PostgreSQL은 그런 구조가 아님. YugabyteDB가 그나마 대안임
대부분의 앱은 몇 시간의 다운타임을 감수함. 대기업만이 복잡한 자동화를 감당할 수 있음 - 가장 흔한 방법은 Patroni를 쓰는 것임. 간단히 하려면 Autobase 사용
Kubernetes 환경이라면 CloudNativePG도 좋음.
pg_auto_failover는 단순하지만 제약이 있음 - 사실 대부분의 비즈니스는 그런 복잡한 HA가 필요 없음. 비용 대비 효과가 낮음
- PostgreSQL 커뮤니티도 이 문제를 인식하고 있음. MongoDB의 내장 복제 안정성을 부러워함
-
Autobase를 보면 self-hosting 시 필요한 작업을 자동으로 처리해줌
- README를 훑어봤는데 커넥션 풀링은 범위 밖인 듯함
- 다른 self-hosted PaaS와도 잘 연동되는지 궁금함. Docker 컨테이너 형태로 동작하는 듯함
- 멋진 프로젝트라 감사함
-
15년 동안 Postgres를 항상 self-hosted로 써왔지만, 문제를 겪은 적은 거의 없음
유일한 고민은 ORM 업그레이드에 맞춰 PG 버전 마이그레이션을 해야 할 때였음. 신중한 시스템 관리로 해결 가능했음 -
Fly.io에서 비관리형 Postgres를 직접 돌렸는데, 정말 고생했음
노드가 자주 죽어서 수동으로 repmgr로 복구해야 했고, 결국 내부 위키에 절차를 정리함
클러스터의 목적이 고가용성인데 왜 좀비 프라이머리를 자동으로 처리하지 않는지 이해가 안 됐음
결국 관리형 Postgres로 옮겼고, 장애 시 다른 사람이 처리해주는 게 정말 편함- 지금은 Fly의 Managed Postgres를 쓰고 있음
-
이 스레드의 많은 댓글이 규모, 워크로드, 인력, 시간, 비즈니스 단계, 확장성 요구 같은 현실적 요소를 무시함
self-hosting이 맞을 수도, 아닐 수도 있는데 논의가 너무 단순함- 엔지니어들은 이런 요소를 거의 고려하지 않고, 상사가 승인할 가장 비싼 솔루션을 택하는 경향이 있음