자, 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는 비용 대비 효율이 높은 자가 호스팅 후보로 평가됨
Postgres는 조금만 관심 있고, 한 지점으로 몰려 있지만 않는다면 Self-Hostiong해도 운영 리스크가 크게 없는 편이죠. 클러스터링과 이중화 솔루션의 선택 폭도 넓고요.
다만 설정을 "잘"했었을 때의 사례라는 설정만 봐도 숙련된 엔지니어가 배치되지 않는다면 고가용성이 실무자 업무의 고가용성으로 전가될 거라 예상됩니다.
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이 맞을 수도, 아닐 수도 있는데 논의가 너무 단순함- 엔지니어들은 이런 요소를 거의 고려하지 않고, 상사가 승인할 가장 비싼 솔루션을 택하는 경향이 있음