Postgres가 새 애플리케이션과 AI 에이전트가 선택하는 기본 데이터베이스가 된 데에는 한 번의 결정적 사건보다 오랜 변화가 겹쳐 작용했다. PlanetScale의 시메온 그릭스(Simeon Griggs)는 Heroku가 2011년 Postgres를 기본 서비스로 내놓은 일, MySQL의 소유권을 둘러싼 불확실성, JSONB 지원과 오픈소스 개발 구조를 주요 전환점으로 꼽는다.
다만 Postgres가 모든 용도에서 MySQL을 대체했다는 뜻은 아니다. MySQL과 Vitess는 여전히 대규모 서비스에 쓰이며, PlanetScale도 MySQL 기반 워크로드를 운영한다. 글은 여러 데이터베이스 선택 추이를 추적하는 도구와 Preseason 순위를 근거로, 대규모 언어 모델(LLM)이 새 애플리케이션에 Postgres를 선택하는 경향이 있다고 설명한다. Preseason 자료는 LLM이 내린 데이터베이스 선택 32,955건의 비중을 집계하며, 호스팅 서비스는 그 기반 엔진에 포함한다.
편리한 호스팅과 개발자 선호
2011년 Heroku는 데이터베이스를 만들고 연결하는 과정을 간편하게 하려는 서비스의 엔진으로 Postgres를 택했다. 당시 팀이 특정 데이터베이스를 강하게 선호한 것은 아니었고, 엔지니어 한 명이 Postgres의 안전성과 신뢰성을 언급한 것이 선택에 영향을 줬다고 한다. 개발자들은 반드시 Postgres 자체를 좋아해서라기보다 Heroku의 편리함을 따라 사용했다.
Heroku는 pg_stat_statements 개선을 지원하고, JSON·JSONB 기능을 두고 Postgres 개발자들과 협력했으며, DATABASE_URL 연결 문자열을 밀었다. 이후에는 Postgres에 기여할 개발자도 고용했다. AWS는 Heroku의 사례에서 영감을 받아 2013년 RDS Postgres를 출시했다. DB-Engines 순위에서 Postgres는 2013년 한 해 36% 상승했다.
“Postgres는 데이터에 대해 안전하고 신뢰할 수 있는 기록을 늘 갖고 있었다. 나는 Postgres를 택하겠다.” — 당시 Heroku 보안·운영 엔지니어의 발언으로, Craig Kerstiens의 회고에 인용됐다.
Heroku가 클라우드 데이터베이스를 쉽게 쓰게 만든 선택은 Postgres를 접하는 사용자층을 키웠다. 글은 엔진 선택 자체는 우연에 가까웠지만, 사용자가 기대하는 편의성을 만든 일이 오늘날의 보급으로 이어졌을 수 있다고 본다.
MySQL의 불확실성과 JSON 지원
MySQL의 창시자는 2009년 오라클의 선 인수 발표 당일 MySQL을 포크해 MariaDB를 만들었다. 오라클은 2010년 1월 선 인수를 마쳤다. MySQL이 대형 상용 데이터베이스 업체의 소유가 되면서 향후 운영 방향에 대한 우려가 생겼고, 커뮤니티도 분열되기 시작했다. 그러나 MySQL의 사용량은 이후에도 수년간 늘었다.
Postgres는 당시 일부 기능에서 뒤처졌지만 따라잡고 있었다. 2010년 출시된 Postgres 9.0에는 복제가 내장됐다. 글은 이것이 MySQL을 택할 실용적인 이유 중 마지막으로 남아 있던 것 가운데 하나를 줄였다고 설명한다. 한편 유튜브는 같은 해 단일 기본 데이터베이스를 넘어 MySQL을 확장하기 위해 Vitess를 만들었다. MySQL은 페이스북과 워드프레스 같은 서비스의 대규모 워크로드를 계속 담당했다.
2013년에는 스택 오버플로 연례 설문에서 Postgres 응답 비율이 45.6%로 MySQL의 41.1%를 처음 앞섰다. 이후에도 선두를 유지했고 격차는 커졌다. 다만 설문은 개발자가 말한 선호를 보여줄 뿐, 실제 사용을 직접 측정한 것은 아니라고 글은 짚는다. 이 추이는 스택 오버플로 설문에서 확인할 수 있다.
문서형 데이터베이스가 관계형 데이터베이스를 위협하던 시기에도 Postgres는 기능을 넓혔다. MongoDB는 스키마 변경이 필요 없는 유연한 구조와 수평 확장을 내세웠고, 자바스크립트·Node 애플리케이션과 잘 맞아 인기를 얻었다. Postgres는 2014년 12월 JSONB를 추가해 JSON 형태의 데이터를 저장하고 색인할 수 있게 했다. MySQL이 비슷한 지원을 추가한 것은 거의 1년 뒤였다. JSONB가 문서형 데이터베이스를 완전히 대체한 것은 아니지만, 관계형 데이터와 비관계형 데이터를 한 데이터베이스에서 다루는 사용 사례를 넓혔다. Postgres 9.4 출시 안내는 이 기능을 소개했다.
초기 개발 구조와 현재의 확산
Postgres의 존속도 처음부터 보장된 것은 아니었다. 버클리에서 마이클 스톤브레이커(Michael Stonebraker)가 시작한 연구 프로젝트는 상용 버전을 만들기 위한 회사 설립 뒤 1994년 버전 4.2에서 끝났다. 대학원생 앤드루 유(Andrew Yu)와 졸리 첸(Jolly Chen)은 다른 프로젝트에 쓸 데이터베이스가 필요해 마지막 버전을 포크해 Postgres95를 만들었다. 이들은 질의 언어를 PostQUEL에서 SQL로 바꾸고 코드베이스를 약 25% 줄였으며, 성능이 30~50% 개선됐다고 밝혔다.
브루스 몘지언(Bruce Momjian)은 1996년 당시 시간제 관리자가 한 명뿐인 Postgres95 프로젝트를 발견했다. 몘지언과 마크 푸르니에(Marc Fournier)는 패치와 출시를 이어가며 이름을 PostgreSQL로 바꿨고, 자원봉사자 그룹은 핵심 팀이 됐다. 글은 단일 소유자가 없는 개발 구조와 버클리의 허용적인 라이선스가 각 클라우드 업체가 Postgres를 제공하고 확장할 수 있는 바탕이 됐다고 설명한다.
초기 설계의 확장성과 확장 프로그램 생태계도 성공 요인으로 제시된다. 버클리의 BSD 계열 라이선스는 폭넓은 채택에 기여했고, 현재 PostgreSQL 라이선스도 이와 유사하다. PlanetScale은 글에서 Postgres를 다양한 컴퓨팅·저장 옵션으로 제공하고 자체 확장 기능도 추가한다고 소개한다.
2025년에는 투자자와 클라우드 제공업체가 개발자들이 이미 선택하던 흐름에 맞춰 투자와 인프라를 늘렸다. PlanetScale도 9월 PlanetScale Postgres를 정식 출시했다. 글에 따르면 스택 오버플로 설문에서 Postgres의 선호도는 한 해 동안 6.9%포인트 상승했다. 에이전트가 데이터베이스를 고를 때도 Postgres를 택하는 사례가 늘었으며, pgvector 덕분에 벡터 전용 데이터베이스를 별도로 선택하지 않고도 에이전트 애플리케이션을 만들 수 있게 됐다고 설명한다.
다만 수평 샤딩처럼 아직 해결되지 않은 사용 사례도 있다. Vitess는 2010년부터 슬랙과 깃허브 같은 서비스에서 샤딩된 MySQL을 지원해 왔다. PlanetScale은 2026년 9월 Vitess 설계와 운영 경험을 바탕으로 한 새 플랫폼 Neki를 플랫폼 프리뷰로 공개했다. PlanetScale은 Neki가 512개 샤드에서 초당 1억 1,800만 건의 질의를 처리했다고 밝혔다. 관련 내용은 Neki 성능 소개에서 볼 수 있다.
글은 Postgres의 부상이 MySQL의 실패를 뜻하지 않는다고 강조한다. 우버는 2016년 Postgres에서 MySQL로 이전했고, MySQL과 Vitess는 계속 사용되고 있다. 오늘날의 기본 선택이 된 배경에는 초기 설계뿐 아니라 개발 편의성, 커뮤니티와 소유 구조, 기능 확장, 클라우드 제공업체의 지원이 함께 작용했다는 것이 글의 결론이다.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요