Postgres면 충분하다

a gist와 활발한 Hacker News thread에서 시작되었다. 전제는 단순했다. Postgres가 모든 것에 최고는 아니지만, 대부분의 것에는 충분히 좋다는 것이다. 실제로는 대부분의 팀이 너무 많은 마이크로서비스와 데이터베이스를 운영하고 있다. 이 모든 것은 성급한 최적화다. 운영 오버헤드는 더 커지고, 유지보수 부담은 더 늘어나며, 모니터링 복잡성은 높아지고, 비용은 증가하고, 추적은 더 어려워지며, 디버깅 세션은 더 길어진다.

전형적인 패턴

캐싱이 필요해서 Redis를 추가한다. 전문 검색은? Elasticsearch를 덧붙인다. 백그라운드 작업은? Redis를 하나 더 쓰거나, 어쩌면 Sidekiq를 쓴다. 유연한 스키마의 문서는? 일단 MongoDB를 선택한다. 분석은? Snowflake. 이벤트는? Kafka를 집어 든다. 그러다 보면 어느새 당신의 "단순한" 애플리케이션은 서로 다른 데이터 저장소와 마이크로서비스 일곱 개와 통신하고 있고, 각각은 자신만의 배포 방식, 백업 전략, 장애 양상, 그리고 서로 대화를 멈추는 새벽 3시의 호출을 갖게 된다. 각 시스템은 운영 표면적을 더한다. 모니터링, 경고, 장애 조치 테스트, 보안 패치, 버전 업그레이드가 모두 늘어난다.

"웹스케일™" 스택

애플리케이션

Redis

Postgres

Elastic

MongoDB

Snowflake

Kafka

Pinecone

Sidekiq

InfluxDB

운영하고 모니터링해야 하는 여러 시스템

Postgres와 함께라면

애플리케이션

PostgreSQL

하나의 데이터베이스. 하나의 백업 전략. 하나의 장애 유형 집합.

"하지만 Postgres는 웹스케일™이 아니잖아!"

우리는 이 주장을 늘 듣는다. 하지만 실제로 소위 "웹스케일"에 도달하는 소프트웨어 프로젝트의 비율이 얼마나 될까? 0.3% 정도일까? 당신의 스텔스 스타트업이나 saas를 위해, 정말로 실제 문제 대신 여러 마이크로서비스와 데이터베이스에 innovation tokens를 태워야 할까?

Notion, Netflix, Instagram 등 수백만 사용자를 서비스하는 회사들이 "지루한" 기술을 신뢰한다면, 당신의 스타트업도 아마 데이터베이스 일곱 개짜리 아키텍처 없이 충분히 해낼 수 있을 것이다. 게다가 언젠가 정말 웹스케일에 도달해서 Postgres의 역량을 모두 소진하게 된다면, 그때 진짜로 필요할 때 필요한 추가 구성 요소를 들여오면 된다.

어쩌면 Postgres면 충분하다

다른 데이터베이스를 집어 들기 전에, Postgres가 이미 제공하는 것으로 해결할 수 있는지 먼저 확인해 보자.

실제로 다른 무언가가 필요할 때

이것은 교조주의에 관한 이야기가 아니다. 때로는 정말로 특화된 인프라가 필요하다. 하지만 기준은 높아야 한다. Postgres를 한계까지 밀어붙여 보고, 왜 그것만으로는 충분하지 않았는지 문서화하고, 대안의 운영 비용을 받아들인 이후에만 그래야 한다. 그전까지는, 당신이 추가하는 모든 시스템은 그 이점이 수년에 걸친 유지보수, 모니터링, 디버깅보다 크다는 데 거는 하나의 베팅이다.