포스트그레가 데이터베이스 세계를 집어삼키고 있다
학습 차원에서 틈틈이 해외 전문가들이 블로그나 미디어 그리고 책에서 쓴 글을 번역 또는 요약 정리하고 있습니다. 이번 포스팅도 그중 하나고요. 거칠고 오역된 부분이 있을 수 있습니다. 제대로 번역되지 않은 부분은 확인 주시면 반영토록 하겠습니다. 의미 전달이 애매한 일부 문장은 삭제했습니다. 이번에는 포스트그레 DB 배포판 회사인 피그스티에 있는 Vonng이 미디엄에 올린 글을 정리한 것입니다.
PostgreSQL은 단순한 관계형 데이터베이스가 아니라 전체 데이터베이스 영역을 아우를 수 있는 잠재력을 지닌 데이터 관리 프레임워크다. "모든 것에 Postgres 사용"이라는 트렌드는 더 이상 소수 엘리트 팀들에만 국한된 것이 아니라 주류 베스트 프랙티스가 되고 있다.
OLAP의 새로운 도전자(OLAP’s New Challenger)
2016년 데이터베이스 밋업에서 나는 PostgreSQL 생태계에서 빠져 있는 것은 OLAP 워크로드를 위한 충분히 우수한 컬럼형 스토리지 엔진의 부재라고 주장했다. PostgreSQL 자체는 많은 분석 기능들을 제공하지만, 대규모 데이터셋에 대한 본격적인 분석 성능은 전용 실시간 데이터 웨어하우스들에 못미친다.
분석 성능 벤치마크인 클릭벤치(ClickBench)에서 PostgreSQL, 생태계 확장 및 파생 데이터베이스 성능을 문서화한 것을 보라. 튜닝되지 않은 PostgreSQL은 성능이 저조하지만(x1050), 최적화를 통해 (x47)에 도달할 수 있다. 이 성능은 특히 MySQL, MariaDB(x3065, x19700)와 같은 순수 OLTP 데이터베이스들과 비교하면 나쁘다고 볼 수 없지만, '충분하지 않은' 수준이다. 사용하기에는 만족스럽지 않지만 버리기에는 너무 좋은, 어려운 지점이다.
하지만 ParadeDB와 DuckDB의 등장으로 판도가 바뀌었다!
ParadeDB의 기본 PG(Postgre) 확장 프로그램인 pg_analytics는 격차를 좁혔고 추가적인 이점을 고려할 때, 이 정도 성능 차이는 종종 용인할 수 있는 수준이다. ElasticSearch 수준 전체 텍스트 검색 기능은 말할 것도 없고, 추가 학습 곡선이 없고, 별도 서비스 유지 관리가 필요 없는 ACID, 최신성 및 실시간 데이터는 말할 것도 없다.
순수 OLAP에 중점을 두고 분석 성능을 극한까지 끌어올린 DuckDB 는 학문적 목적의 비공개 소스 데이터베이스인 Umbra를 제외하면, 실용적인 OLAP 성능에서 가장 빠르다는 것은 틀림없다. PG 확장은 아니지만, PostgreSQL은 임베디드 파일 데이터베이스로서 DuckDB 분석 성능 향상을 DuckDB FDW 및 pg_quack과 같은 프로젝트를 통해 충분히 활용할 수 있다. ParadeDB와 DuckDB의 등장은 PostgreSQL의 분석 기능을 OLAP 최상위급으로 끌어올리며 분석 성능의 마지막 중요한 격차를 메워준다.
데이터베이스 영역의 추(The Pendulum of Database Realm)
데이터베이스 초창기에는 OLTP와 OLAP 구분이 존재하지 않았다. 데이터베이스에서 OLAP 데이터 웨어하우스가 분리된 것은 1990년대에 기존 OLTP 데이터베이스가 분석 시나리오 쿼리 패턴과 성능 요구 사항을 지원하는 데 어려움을 겪으면서부터다.
오랫동안 데이터 처리 모범 사례는 OLTP 워크로드에 MySQL/PostgreSQL을 사용하고 ETL 프로세스를 통해 데이터를 Greenplum, ClickHouse, Doris, Snowflake 등과 같은 전문 OLAP 시스템으로 동기화하는 것이었다.
많은 '전문 데이터베이스'들과 마찬가지로, 전용 OLAP 시스템이 갖는 강점은 성능에 있는 경우가 많다. 기본 PostgreSQL 또는 MySQL에 비해 1~3배의 성능 향상을 달성할 수 있다. 그러나 그 대가로 데이터 중복, 과도한 데이터 이동, 분산된 구성 요소 들간 데이터 값에 대한 합의 부족, 전문 기술에 대한 추가 인건비, 추가 라이선스 비용, 제한된 쿼리 언어 능력, 프로그래밍 가능성 및 확장성, 제한된 도구 통합, 완전한 DMBS에 비해 낮은 데이터 무결성 및 가용성 등의 문제가 발생할 수 있다.
하지만 무어의 법칙에 따라 30년 넘게 하드웨어가 개선되면서 성능은 기하급수적으로 증가한 반면 비용은 급감했다. 2024년에는 단일 x86 서버에 수백 개 코어(512 vCPU, EPYC 9754 x2), 수 TB RAM, 단일 NVMe SSD가 최대 64TB/3M 4K 랜드 IOPS/14GB/s, 단일 올플래시 랙이 수 PB에 달할 수 있으며 S3 같은 오브젝트 스토리지는 사실상 무제한 스토리지를 제공할 수 있을 것이다.
3년마다 두 배로 증가하는 I/O 대역폭
하드웨어 발전으로 데이터 용량과 성능 문제가 해결되었고, 데이터베이스 소프트웨어(PostgreSQL, ParadeDB, DuckDB) 발전으로 액세스 방식 문제가 해결됐다. 이로 인해 소위 '빅 데이터' 산업이라 불리는 분석 부문의 기본 가정이 재검토되고 있다.
DuckDB의 선언문 "빅데이터는 죽었다"에서 알 수 있듯이, 빅데이터의 시대는 끝났다. 대부분의 사람들은 그렇게 많은 데이터를 가지고 있지 않으며, 대부분 데이터는 쿼리에 거의 활동되지 않는다. 하드웨어와 소프트웨어가 발전함에 따라 빅 데이터의 경계가 희미해지면서 99% 시나리오에서는 '빅 데이터' 렌더링이 필요하지 않게 됐다.
이제 99% 사용 사례를 독립형 PostgreSQL/DuckDB(및 그 복제본)를 통해 단일 컴퓨터에서 처리할 수 있다면 전용 분석 컴포넌트를 사용할 이유가 있을까? 모든 스마트폰이 자유롭게 문자를 주고받을 수 있다면 호출기는 무슨 소용이 있을까? (북미 병원들에선 여전히 호출기를 사용한다는 점을 감안하면, '빅 데이터'가 진정으로 필요한 시나리오는 1% 미만일 수도 있다)
근본적인 가정이 바뀌면서 데이터베이스 세계는 다양화 단계에서 다시 융합 단계로, 빅뱅(big bang)에서 대량 멸종(mass extinction)으로 전환되고 있다. 이 과정에서 통합된 다중 모델 슈퍼 컨버지드 데이터베이스의 새로운 시대가 도래해 OLTP와 OLAP이 재결합할 것이다. 그렇다면 데이터베이스 분야를 재통합하는 이 기념비적인 작업을 누가 주도할까?
바로 PostgreSQL이다: 데이터베이스계의 포식자
데이터베이스 영역에는 시계열, 지오스페이셜(geospatial), 문서, 검색, 그래프, 벡터 데이터베이스, 메시지 큐, 객체 데이터베이스 등 많은 틈새 시장들이 있다. PostgreSQL은 이러한 모든 영역에서 그 존재감을 드러내고 있다. 예를 들어, 지오 스페이셜 데이터베이스에서 사실상의 표준을 설정하는 PostGIS 확장 기능, "일반적인" 시계열 데이터베이스를 배치하는 TimescaleDB 확장 기능, 전용 벡터 데이터베이스 틈새 시장을 개척한 벡터 확장 기능인 PGVector가 있다. 이러한 현상은 처음이 아니라 가장 오래되고 가장 큰 하위 도메인에서 다시 나타나고 있다: OLAP 분석이다. 하지만 PostgreSQL의 야망은 OLAP에서 멈추지 않고 전체 데이터베이스 세계를 주목하고 있다!
PostgreSQL이 이렇게 뛰어난 이유는 무엇일까? PostgreSQL는 첨단이지만 오라클도 그렇다. 오픈소스지만 MySQL도 오픈소스다. PostgreSQL장점은 진화돼 있는 동시에 오픈 소스이기 때문에 오라클/MySQL과 경쟁할 수 있다는 점이다. 그러나 진정한 독특함은 뛰어난 확장성과 번성하는 확장 생태계다.
뛰어난 확장성의 마법
PostgreSQL은 단순한 관계형 데이터베이스가 아니라 전체 데이터베이스 세계를 아우를 수 있는 데이터 관리 프레임워크다. 오픈 소스이며 고급이라는 점 외에도 핵심 경쟁력은 확장성, 즉 인프라 재사용성과 확장 기능의 구성 가능성에서 비롯된다.
PostgreSQL을 사용하면 데이터베이스 공통 인프라를 활용해 최소 비용으로 확장 기능을 개발할 수 있다. 예를 들어, 수천 줄 코드에 불과한 벡터 데이터베이스 확장 프로그램인 pgvector는 수백만 줄에 달하는PostgreSQL에 비해 복잡성이 무시할 수 있는 수준이다. 하지만 이 '미미한' 확장 기능은 완벽한 벡터 데이터 유형과 인덱싱 기능을 구현해 많은 전문 벡터 데이터베이스보다 뛰어난 성능을 발휘한다.
왜 그럴까? pgvector 제작자들은 데이터베이스와 관련해 일반적인 추가 복잡성에 대해 걱정할 필요가 없었기 때문이다: 수백만 줄 코드가 필요한 ACID, 복구, 백업 및 PITR, 고가용성, 액세스 제어, 모니터링, 배포, 타사 에코시스템 도구, 클라이언트 드라이버 등을 제대로 해결하려면 수백만 줄의 코드가 필요하다. 그들은 문제의 본질적인 복잡성에만 집중했다.
예를 들어, ElasticSearch는 Lucene 검색 라이브러리를 기반으로 개발됐고 Rust 생태계에는 Lucene의 대안으로 개선된 차세대 전체 텍스트 검색 라이브러리인 Tantivy가 있다. ParadeDB는 이를 래핑하고 PostgreSQL 인터페이스에 연결하기만 하면 ElasticSearch와 비슷한 검색 서비스를 제공할 수 있다. 더 중요한 것은, 전체 PG 생태계의 단합된 힘(예: pgvector를 사용한 하이브리드 검색)을 활용해 다른 전용 데이터베이스와 경쟁할 수 있다는 점이다.
확장성은 또 다른 큰 장점인 확장 기능 구성 가능성(composability)을 통해 서로 다른 확장 기능들을 함께 사용할 수 있어 1+1" 2보다 큰 시너지 효과를 창출할 수 있다. 예를 들어, 타임스케일DB는 공간-시간 데이터 지원을 위해 PostGIS와 결합할 수 있고, 전체 텍스트 검색을 위한 BM25 확장 기능은 PGVector 확장 기능과 결합해 하이브리드 검색 기능을 제공할 수 있다.
분산 확장 기능인 Citus는 독립형 클러스터를 수평적으로 파티션된 분산 데이터베이스 클러스터로 투명하게 변환할 수 있다. 이 기능은 다른 기능들과 결합할 수 있어, PostGIS는 분산형 지오 스페이셜 데이터베이스로, PGVector는 분산형 벡터 데이터베이스로, ParadeDB는 분산형 전체 텍스트 검색 데이터베이스로 만들 수 있다.
더욱 강력한 점은 메인 브랜치(main branch)를 합치고 조정하는 번거로움 없이 확장 기능들이 독립적으로 발전한다는 것이다. PG의 확장성 덕분에 수많은 팀들은 동시에 데이터베이스 가능성을 탐색할 수 있으며, 모든 확장 기능들은 핵심 기능의 안정성에 영향을 주지 않는 선택 사항이다. 성숙하고 견고한 기능은 메인 브랜치에 안정적으로 통합할 수 있다.
탁월한 확장성의 마법을 통해 기본적인 안정성과 민첩한 기능을 모두 달성한 PostgreSQL은 데이터베이스 업계에서 독보적인 존재가 되어 데이터베이스 환경의 게임 규칙을 바꾸고 있다.
데이터베이스 업계의 판도를 바꾸는 게임 체인저
PostgreSQL의 등장으로 데이터베이스 영역의 패러다임이 바뀌고 있다: '새로운 데이터베이스 커널'을 만들기 위해 노력하는 팀들은 이제 오픈 소스의 풍부한 기능을 갖춘 Postgres와 경쟁해야 하는 엄청난 시련에 직면해 있다. 이들의 고유한 가치 제안은 무엇일까?
혁신적인 하드웨어 혁신이 일어나기 전까지는 실용적이고 새로운 범용 데이터베이스 커널이 등장할 가능성은 희박해 보인다. PG의 장점인 오픈 소스 및 무료라는 점을 고려할 때, 모든 확장 기능으로 강화된 PG의 전반적인 성능에 필적할 수 있는 단일 데이터베이스는 없다(심지어 오라클도 마찬가지다).
틈새 데이터베이스 제품들은 특정 측면(일반적으로 성능)에서 PostgreSQL보다 월등히 뛰어난 성능을 발휘할 수 있다면 스스로 입지를 개척할 수 있다 그러나 완전히 새로운 데이터베이스를 개발하는 대신 PG 확장 프로그램을 개발하기로 선택하면 팀들은 따라잡는 데 있어 엄청난 속도 이점을 얻을 수 있다. 이러한 논리에 따라, PostgreSQL 생태계는 눈덩이처럼 커지면서 장점을 쌓아가고 필연적으로 몇 년 안에 서버 OS에서 Linux 커널이 갖는 지위를 반영하는 독점을 향해 나아갈 준비가 되어있다. 개발자 설문조사와 데이터베이스 트렌드 보고서에서 이러한 추세를 확인할 수 있다.
PostgreSQL은 오랫동안 HackerNews와 StackOverflow에서 가장 인기 있는 데이터베이스였다. 많은 신규 오픈소스 프로젝트들에서 기본 데이터베이스로 PostgreSQL을 선택하기도 한다. 그리고 많은 스타트업들도 PostgreSQL에 올인하고 있다.
"급진적 단순성: Postgres를 사용하라"(Radical Simplicity: Just Use Postgres)라는 제목에서 알 수 있듯이, 기술 스택을 단순화하고, 구성 요소를 줄이고, 개발을 가속화하고, 위험을 낮추고, 더 많은 기능을 추가하는 것은 "그냥 Postgres를 사용하라"를 통해 달성할 수 있다. Postgres는 수백만 명 사용자에게 손쉽게 서비스를 제공해 MySQL, Kafka, RabbitMQ, ElasticSearch, Mongo, Redis를 비롯한 많은 백엔드 기술을 대체할 수 있다 이제 Postgres 사용은 더 이상 소수의 엘리트 팀에만 국한되지 않고 주류 베스트 프랙티스가 되고 있다.
그 밖에 뭘 할 수 있을까?
데이터베이스 도메인의 최종 목표는 예측 가능해 보인다. 우리는 무엇을 할 수 있고 무엇을 해야 할까? PostgreSQL은 이미 대부분의 시나리오들에서 거의 완벽한 데이터베이스 커널이기 때문에 커널 '병목 현상'이라는 개념은 터무니없다. 커널 수정을 판매 포인트로 선전하는 PostgreSQL과 MySQL 포크는 기본적으로 효과가 없다.
이는 오늘날 Linux OS 커널의 상황과 유사하다.수많은 Linux 배포판들이 있음에도 모두가 동일한 커널을 선택한다. Linux 커널을 포크하는 것은 불필요한 어려움을 야기하는 것으로 간주되어 업계에서는 이를 꺼려한다.
따라서 주요 갈등은 더 이상 데이터베이스 커널 자체가 아니라 데이터베이스 확장 및 서비스라는 두 가지 방향이다! 전자는 내부 확장성과 관련된 것이고, 후자는 외부 구성 가능성과 관련된 것이다. OS 생태계와 마찬가지로 경쟁 환경은 데이터베이스 배포에 집중될 것입니다. 데이터베이스 영역에서는 확장성과 서비스를 중심으로 하는 배포판만이 궁극적인 성공의 기회를 잡을 수 있다.
커널은 여전히 뜨뜨미지근하다. MySQL 포크 버전인 MariaDB는 상장 폐지를 앞두고 있는 반면, 무료 커널을 기반으로 서비스와 확장 기능을 제공하여 수익을 올리는 AWS는 번창하고 있다. 수많은 PG 생태계 확장 및 서비스 배포에 투자금이 유입되고 있다: Citus, TimescaleDB, Hydra, PostgresML, ParadeDB, FerretDB, StackGres, Aiven, Neon, Supabase, Tembo, PostgresAI, 그리고 자체 PG 배포판 - - Pigsty.
PostgreSQL 생태계의 딜레마는 많은 확장 기능과 도구가 독립적으로 발전하면서 시너지를 낼 수 있는 통합 관리자가 없다는 것이다. 예를 들어, Hydra는 자체 패키지와 Docker 이미지를 출시하고, PostgresML도 각각 자체 확장과 함께 PostgreSQL 이미지를 배포하며, 자체 확장 프로그램만 배포한다. 이러한 이미지와 패키지는 AWS RDS와 같은 포괄적인 데이터베이스 서비스와는 거리가 멀다.
AWS와 같은 서비스 제공자와 생태계 통합자조차도 여러 가지 이유(AGPLv3 라이선스, 멀티테넌시의 보안 문제)들로 인해 많은 확장 기능을 포함하지 못해 PostgreSQL 생태계 확장 기능의 시너지 증폭 잠재력을 활용하지 못하고 있다.
많은 중요한 확장 기능들이 Cloud RDS에서 제공되지 않는다. 확장 기능은 PostgreSQL의 핵심이다. 확장 기능을 자유롭게 사용할 수 없는 Postgres는 소금 없이 요리하는 것과 같으며, 거대한 제약을 받다.
이 문제를 해결하는 것이 우리의 주요 목표들 중 하나다.
우리의 해결책
MySQL과 MSSQL을 먼저 접했음에도 불구하고, 2015년에 PostgreSQL을 처음 사용했을 때 나는 데이터베이스 영역에서 이 기술이 향후 지배적인 위치를 차지할 것이라고 확신했다. 거의 10년이 지난 지금, 나는 사용자이자 관리자에서 기여자이자 개발자로 전환해 그 목표를 향한 PG의 행보를 목격하고 있다. 다양한 사용자들과 상호작용을 통해 데이터베이스 분야 단점은 더 이상 커널이 아니라 이미 PostgreSQL로 충분하다는 것을 알게 되었다. 진짜 문제는 커널의 기능을 활용하는 것이며, 이것이 바로 RDS가 급성장한 이유다.
하지만 나는 이 기능을 사이버 봉건 영주로부터 빌려 쓰는 것이 아니라 모든 사용자가 PostgreSQL 커널 자체처럼 무료 소프트웨어처럼 이용할 수 있어야 한다고 생각한다. 그래서 나는 오픈 소스 RDS 대안으로 로컬 퍼스트 PostgreSQL 배포판인 Pigsty를 만들었으며, 이는 PostgreSQL 생태계 확장의 집단적 힘을 활용하고 프로덕션급 데이터베이스 서비스에 대한 액세스를 민주화하는 것을 목표로 하고 있다.
Pigsty는 훌륭한 스타일의 PostgreSQL을 의미한다. 우리는 PostgreSQL 데이터베이스 서비스의 핵심 문제를 다루는 6가지 핵심 명제를 정의했다.: 확장 가능한 Postgres, 안정적인 인프라, 관찰 가능한 그래픽, 사용 가능한 서비스, 유지 관리 가능한 도구 상자, 컴포저블 모듈이다. 확장 가능한 PostgreSQL은 Pigsty의 핵심이다.최근 출시된 Pigsty v2.6에서는 DuckDB FDW와 ParadeDB 확장 기능을 통합해 PostgreSQL 분석 기능을 대폭 강화했으며 모든 사용자가 이 기능을 쉽게 활용할 수 있도록 했다. 우리 목표는 데이터베이스계의 우분투와 같은 시너지 효과를 창출해 PostgreSQL 생태계내 강점을 통합하는 것이다. 커널 논쟁은 이제 끝났으며, 진정한 경쟁의 장은 바로 여기에 있다고 생각한다.
