2025년 데이터베이스 업계의 주요 흐름과 사건들을 정리한다. PostgreSQL의 지속적인 우세, MCP 확산, MongoDB와 FerretDB의 법적 분쟁, 파일 포맷 경쟁, 인수합병·펀딩·사망 소식, 그리고 Larry Ellison의 한 해까지 폭넓게 다룬다.
URL: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-retrospective.html
2026년 1월 04일 게시
또 한 해가 지나갔다. 연말 결산 글 말고 더 많은 글을 쓰고 싶었는데, 봄 학기에 거의 죽을 뻔했고, 그게 내 시간을 다 잡아먹었다. 그래도 지난 한 해 데이터베이스에서 일어났다고 내가 생각하는 주요 흐름과 사건들을 훑어보겠다.
데이터베이스 세계에는 흥미롭고 전례 없는 일들이 많았다. 바이브 코딩이 일상 용어로 들어왔고, 우탱 클랜(Wu-Tang Clan)은 타임 캡슐 프로젝트를 발표했다. 그리고 올해 한 번의 거대한 펀딩 라운드를 하고 상장하는 대신, Databricks는 상장 대신 두 번의 거대한 라운드를 올렸다.
한편 다른 사건들은 예상 가능했고 덜 놀라웠다. Redis Ltd.는 러그풀 1년 만에 라이선스를 다시 되돌렸고 (이건 내가 작년에 예언했다), SurrealDB는 쓰기 내용을 디스크에 플러시하지 않아 데이터가 유실되었는데도 훌륭한 벤치마크 수치를 보고했고, Coldplay는 결혼을 파탄낼 수도 있다. 그래도 Astronomer는 마지막 건으로 꽤 괜찮은 레모네이드를 만들긴 했다.
시작하기 전에, 매년 이 글 댓글에서 받는 질문을 하나 짚고 넘어가겠다. 사람들은 왜 내가 어떤 시스템, 데이터베이스, 또는 회사를 언급하지 않느냐고 묻는다. 나는 한정된 것만 쓸 수 있고, 지난 한 해 동안 흥미롭거나 주목할 만한 일이 없었다면 논할 게 없다. 또 모든 주목할 만한 데이터베이스 사건이 내가 의견을 보태기 적절한 것도 아니다. 예컨대 최근 AvgDatabase CEO의 신원 공개 시도는 이야기할 만하지만, MongoDB 자살 소송은 확실히 아니다.
자, 그럼 시작하자. 해마다 글이 더 길어지고 있어서 미리 사과한다.
이전 글:
2021년에 나는 PostgreSQL이 데이터베이스 세계를 먹어치우고 있다고 처음 썼다. 이 흐름은 멈추지 않았고, 데이터베이스 세계에서 가장 흥미로운 발전 대부분이 다시 한 번 PostgreSQL에서 벌어지고 있다. DBMS의 최신 버전(v18)은 2025년 11월에 나왔다. 가장 눈에 띄는 기능은 새 비동기 I/O 저장소 서브시스템으로, 마침내 PostgreSQL을 OS 페이지 캐시 의존에서 벗어나게 하는 길로 올려놓는다. 또한 스킵 스캔(skip scan)을 지원해, 선행 키(즉 프리픽스)가 빠져 있어도 다중 키 B+Tree 인덱스를 쿼리가 사용할 수 있다. 쿼리 옵티마이저도 추가 개선(예: 불필요한 셀프 조인 제거)이 있었다.
노련한 데이터베이스 감식가들은 “이건 혁신적인 기능이 아니고 다른 DBMS들은 수년 전부터 있던 거다”라고 재빨리 지적할 것이다. PostgreSQL은 아직도 OS 페이지 캐시에 의존하는 유일한 주요 DBMS이고, Oracle은 2002년(v9i)부터 스킵 스캔을 지원했다! 그럼 왜 내가 2025년 데이터베이스에서 가장 뜨거운 움직임이 PostgreSQL에서 일어났다고 말하느냐고?
이유는 데이터베이스 업계의 에너지와 활동 대부분이 PostgreSQL 회사, 제품, 프로젝트, 파생 시스템으로 몰리고 있기 때문이다.
지난 1년 동안 가장 뜨거운 데이터 스타트업(Databricks)은 PostgreSQL DBaaS 회사(Neon)를 10억 달러에 인수했다. 이어서 세계 최대급 데이터베이스 회사 중 하나(Snowflake)가 또 다른 PostgreSQL DBaaS 회사(CrunchyData)를 2억5천만 달러에 인수했다. 그다음 지구상 최대급 테크 기업(마이크로소프트)은 새 PostgreSQL DBaaS인 HorizonDB를 출시했다. Neon과 HorizonDB는 2010년대 Amazon Aurora의 원래 고수준 아키텍처를 따르며, 단일 프라이머리 노드에서 컴퓨트와 스토리지를 분리한다. 반면 Snowflake의 PostgreSQL DBaaS는 현재로선 표준 PostgreSQL과 같은 코어 아키텍처를 쓰는데, Crunchy Bridge 위에 구축했기 때문이다.
위에서 언급한 서비스들은 모두 단일 프라이머리 노드 아키텍처다. 즉 애플리케이션은 프라이머리 노드에 쓰기를 보내고, 그 변경분이 세컨더리 레플리카로 전달된다. 하지만 2025년에는 PostgreSQL을 위한 스케일아웃(즉 수평 파티셔닝) 서비스 프로젝트 두 개가 발표됐다.
2025년 6월, Supabase는 Vitess 공동 창시자이자 전 PlanetScale 공동창업자/CTO인 Sugu를 영입해, MySQL을 Vitess가 샤딩하듯 PostgreSQL에 샤딩 미들웨어를 제공하는 Multigres 프로젝트를 이끌게 했다고 발표했다. Sugu는 2023년에 PlanetScale을 떠났고 2년간 몸을 낮춰야 했다. 이제는 법적 문제에서 벗어났을 가능성이 크고 Supabase에서 일을 벌일 수 있게 된 듯하다. 데이터베이스 엔지니어가 어떤 회사에 합류했는데 발표문이 시스템보다 사람에 더 초점을 맞추면, 그건 큰일이다. SingleStore의 공동창업자/CTO가 2024년에 마이크로소프트로 옮겨 HorizonDB를 이끌게 됐다지만, 마이크로소프트는 (잘못도) 이를 크게 알리지 않았다. Sugu의 Supabase 합류는 마치 Ol' Dirty Bastard (RIP)가 2년 만에 가석방으로 나와서, 석방 첫날 새 레코드 계약을 발표하는 것과 비슷하다.
Multigres 소식이 나온 한 달 뒤 PlanetScale은 PostgreSQL용 Vitess 프로젝트인 Neki를 발표했다. PlanetScale은 2025년 3월 초기 PostgreSQL DBaaS를 출시했지만, 코어 아키텍처는 단일 노드의 순정 PostgreSQL + pgBouncer다.
2025년 HorizonDB 도입으로, 이제 모든 주요 클라우드 벤더가 자사 PostgreSQL 제품을 진지하게 추진한다. Amazon은 2017년부터 Aurora PostgreSQL을 제공해왔다. Google은 2022년에 AlloyDB를 내놨다. ServiceNow는 2021년 Swarm64 인수를 바탕으로 2024년 RaptorDB 서비스를 출시했다. ‘피처폰’ IBM조차 2018년부터 클라우드 PostgreSQL을 갖고 있다. Oracle은 2023년에 PostgreSQL 서비스를 출시했지만, 2025년 9월 MySQL OCI 감원의 여파로 사내 PostgreSQL 팀이 타격을 받았다는 소문이 있다.
독립(ISV) PostgreSQL DBaaS 회사도 몇 곳 남아 있다. Supabase는 인스턴스 수로는 아마 최대일 것이다. 그 밖에 YugabyteDB, TigerData (구 TimeScale), PlanetScale, Xata, PgEdge, Nile 등이 있다. Xata는 초기 아키텍처를 Amazon Aurora 위에 올렸지만, 올해 자체 인프라로 전환한다고 발표했다. ParadeDB는 아직 호스티드 서비스를 발표하지 않았다. Tembo는 2025년에 호스티드 PostgreSQL을 접고, DB 튜닝을 일부 수행하는 코딩 에이전트로 피벗했다. Hydra와 PostgresML은 2025년에 망했다(사망 섹션 참고). 또한 프런트엔드만 Postgres 호환이고 백엔드는 PostgreSQL 파생이 아닌 시스템들도 있다(예: CockroachDB, CedarDB, Google Spanner). Aiven, Tessel처럼 여러 DBaaS를 함께 제공하는 호스팅 회사들도 있다.
Andy의 견해Databricks와 Snowflake가 PostgreSQL 회사를 인수한 뒤 다음 큰 인수자는 누구일지 불분명하다. 다시 말해, 이미 모든 주요 테크 회사는 Postgres 제품을 갖고 있다. EnterpriseDB는 가장 오래된 PostgreSQL ISV지만, 지난 5년간 가장 큰 PostgreSQL 인수 두 건에서 소외됐다. 그래도 Bain Capital의 지원을 좀 더 타고 가거나, 8년 전의 파트너십에도 불구하고 HPE가 인수해주길 기대할 수도 있다. PostgreSQL M&A 판은 2000년대 후반 OLAP 인수전이 떠오른다. AsterData, Greenplum, DATAllegro가 인수된 뒤, Vertica만이 마지막까지 버스정류장에 남아 있던 그때처럼.
경쟁하는 두 분산 PostgreSQL 프로젝트(Multigres, Neki)의 등장은 반가운 소식이다. 물론 이런 시도는 처음이 아니다. OLAP 분야에선 Greenplum, ParAccel, Citus가 20년째 존재한다. Citus는 OLTP도 지원하지만, 2010년 시작 당시엔 분석에 집중했다. OLTP 쪽으로는 15년 전 NTT RiTaDB가 GridSQL과 합쳐 Postgres-XC를 만들었다. Postgres-XC 개발자들은 StormDB를 창업했고, Translattice가 2013년에 이를 인수했다. Postgres-X2는 XC 현대화 시도였지만 중단됐다. Translattice는 StormDB를 Postgres-XL로 오픈소스화했으나, 프로젝트는 2018년 이후 휴면 상태다. YugabyteDB는 2016년에 등장했고, 아마 가장 널리 배포된 샤딩 PostgreSQL 시스템일 것이다(그리고 여전히 오픈소스!). 다만 하드 포크라서 PostgreSQL v15까지만 호환된다. Amazon은 2024년에 자체 샤딩 PostgreSQL(Aurora Limitless)을 발표했지만, 클로즈드 소스다.
마이크로소프트가 2019년에 Citus를 인수했다는 건 알지만, HorizonDB 이전에 뭘 하고 있었는지는 제품명이 너무 혼란스러워서 따라가기 어렵다. Citus는 2019년에 Azure Database for PostgreSQL Hyperscale로 리브랜딩됐다가, 2022년에 Azure Cosmos DB for PostgreSQL로 또 바뀌었다. 그런데 Azure Database for PostgreSQL with Elastic Clusters라는 것도 있는데, 이것도 Citus를 쓰지만 Citus 기반 Azure Cosmos DB for PostgreSQL과 같은 것은 아니다. 마이크로소프트는 2023년에 Azure PostgreSQL Single Server를 종료했지만 Azure PostgreSQL Flexible Server는 유지했다. Azure 이것저것이 너무 많다. Amazon이 DSQL 이름에까지 “Aurora”를 붙이고 싶어 했던 것과 비슷하다. 어쨌든 마이크로소프트가 (현재로서는) 새 시스템 이름을 그냥 “Azure HorizonDB”로 정한 건 현명했다.
PlanetScale 진영은 상대에게 정이 없고, Neon과 Timescale에게도 손찌검을 잘하기로 유명하다. 데이터베이스 회사들끼리의 설전은 새삼스러운 일이 아니다(Yugabyte vs. CockroachDB나 Databricks vs. Snowflake 참고). PostgreSQL 전쟁이 달아오르면서 앞으로 더 많이 보게 될 것 같다. 나는 이 작은 회사들이 큰 클라우드 벤더를 콜아웃하고, 서로의 이름은 입에 담지 말았으면 한다.
2023년이 모든 DBMS가 벡터 인덱스를 추가한 해였다면, 2025년은 모든 DBMS가 Anthropic의 Model Context Protocol(MCP)을 지원한 해였다. MCP는 표준화된 클라이언트-서버 JSON-RPC 인터페이스로, LLM이 커스텀 글루 코드 없이 외부 도구와 데이터 소스와 상호작용할 수 있게 한다. MCP 서버는 DBMS 앞단의 미들웨어로 동작하며, 제공 가능한 도구·데이터·액션 목록을 노출한다. MCP 클라이언트(예: Claude나 ChatGPT 같은 LLM 호스트)는 이를 발견해 서버에 요청을 보내 모델의 능력을 확장한다. 데이터베이스의 경우 MCP 서버는 요청을 적절한 데이터베이스 쿼리(예: SQL)나 관리 명령으로 변환한다. 즉 MCP는 벽돌은 세고 크림은 곧게 유지해, 데이터베이스와 LLM이 서로를 믿고 거래하게 해주는 중개상이다.
Anthropic은 2024년 11월 MCP를 발표했지만, 2025년 3월 OpenAI가 자사 생태계에서 MCP 지원을 발표하면서 본격적으로 폭발했다. 이후 몇 달 사이 모든 DBMS 벤더가 각 카테고리별 MCP 서버를 출시했다: OLAP(예: ClickHouse, Snowflake, Firebolt, Yellowbrick), SQL(예: YugabyteDB, Oracle, PlanetScale), NoSQL(예: MongoDB, Neo4j, Redis). 공식 Postgres MCP 서버가 없기 때문에, 모든 Postgres DBaaS는 자체 서버를 내놨다(예: Timescale, Supabase, Xata). 클라우드 벤더들은 자사 관리형 DB 서비스들과 대화할 수 있는 멀티 DB MCP 서버도 내놨다(예: Amazon, Microsoft, Google). 하나의 게이트웨이로 이기종 데이터베이스를 다룰 수 있다는 점에서, 이는 거의(하지만 완전히는 아닌) 성배 같은 연합(federated) 데이터베이스에 가깝다. 내가 아는 한, 각 요청은 한 번에 단일 데이터베이스만 대상으로 하므로, 소스 간 조인은 애플리케이션이 담당해야 한다.
공식 벤더 구현 외에도, 거의 모든 DBMS에 대한 잡다한 MCP 서버 구현이 수백 개 있다. 일부는 여러 시스템을 지원하려 한다(예: DBHub, DB MCP Server). DBHub는 PostgreSQL MCP 서버들에 대한 좋은 개요를 내놨다.
에이전트에게 유용한 기능으로는 데이터베이스 브랜칭이 있다. MCP 서버에만 국한된 것은 아니지만, 브랜칭은 프로덕션에 영향을 주지 않고 데이터베이스 변경을 빠르게 시험하게 해준다. Neon은 2025년 7월 에이전트가 자신들의 DB의 80%를 생성한다고 보고했다. Neon은 처음부터 브랜칭을 지원하도록 설계됐다(시스템이 아직 “Zenith”라고 불리던 시절, Nikita가 내게 초기 데모를 보여줬다). 다른 시스템들은 이후에 브랜칭을 추가했다. 브랜칭에 관한 Xata의 최근 비교 글을 보라.
Andy의 견해한편으로는, 이제 데이터베이스를 더 많은 애플리케이션에 노출하는 표준이 생겨서 기쁘다. 하지만 MCP든 기존 API든, 어떤 애플리케이션에도 무제한 데이터베이스 접근권을 줘서는 안 된다. 계정에는 최소 권한만 부여하는 것이 여전히 모범 사례다. 감시되지 않는 에이전트는 데이터베이스를 난장판으로 만들 수 있기 때문에 계정 제한은 특히 중요하다. 즉 모든 계정에 관리자 권한을 주거나 모든 서비스가 같은 계정을 쓰는 게으른 관행은 LLM이 날뛰기 시작하면 박살날 것이다. 물론 당신 회사가 데이터베이스를 세상에 활짝 열어둔 채 세계에서 가장 부유한 회사 중 하나의 주가를 6천억 달러나 떨어뜨리는 일을 하고 있다면, 불량 MCP 요청은 최우선 걱정거리는 아닐 것이다.
몇몇 MCP 서버 구현을 대충 훑어본 결과, 이들은 MCP JSON 요청을 DB 쿼리로 변환하는 단순 프록시에 가깝다. 요청이 무엇을 하려는지, 그것이 적절한지에 대한 깊은 의미 분석은 없다. 누군가는 애플리케이션에서 물컵 18,000개를 주문하려 할 것이고, 당신은 그게 DB를 죽이지 않도록 해야 한다. 일부 MCP 서버는 기본적인 방어(예: ClickHouse는 읽기 전용 쿼리만 허용)를 제공한다. DBHub는 요청당 반환 레코드 수 제한, 쿼리 타임아웃 같은 추가 보호 장치를 제공한다. Supabase 문서는 MCP 에이전트를 위한 베스트 프랙티스 가이드를 제공하지만, 결국 사람에게 의존한다. 그리고 사람에게 올바른 행동을 기대하면 나쁜 일이 생긴다.
엔터프라이즈 DBMS들은 오픈소스 시스템에 없는 자동 가드레일과 안전 장치가 이미 있어서, 에이전트 생태계에 더 준비되어 있다. 예컨대 IBM Guardium과 Oracle Database Firewall은 이상 쿼리를 식별하고 차단한다. 내가 이 대기업들을 광고하려는 건 아니다. 하지만 앞으로 에이전트가 사람 인생을 망치는 사례(예: 실수로 데이터베이스를 드롭)는 더 나올 것이다. MCP 서버와 프록시(예: 커넥션 풀링)를 결합하는 건 자동 보호 장치를 넣을 좋은 기회다.
MongoDB는 20년째 NoSQL의 버팀목이다. FerretDB는 2021년에 Percona의 핵심 인력들이 시작했으며, MongoDB 쿼리를 PostgreSQL 백엔드용 SQL로 바꿔주는 미들웨어 프록시를 제공한다. 이 프록시 덕분에 MongoDB 애플리케이션은 쿼리를 다시 쓰지 않고 PostgreSQL로 갈아탈 수 있다.
몇 년간 공존하던 두 회사 사이에, MongoDB가 2023년에 FerretDB에 내용증명(cease-and-desist)을 보내 특허·저작권·상표 침해, 그리고 문서 및 와이어 프로토콜 명세에 대한 MongoDB 라이선스 위반을 주장했다. 이 서한은 2025년 5월, MongoDB가 FerretDB에 대해 연방 소송을 제기하면서 공개됐다. 문제의 일부는 FerretDB가 허가 없이 MongoDB의 “드롭인 대체재”라고 주장한다는 점이다. MongoDB의 소장에는 (1) 개발자 오도, (2) 상표 희석, (3) 평판 훼손 같은 전형적 주장이 들어 있다.
여기에 마이크로소프트가 MongoDB 호환 DocumentDB를 리눅스 재단에 기부했다는 발표로 이야기가 더 복잡해졌다. 프로젝트 웹사이트는 DocumentDB가 MongoDB 드라이버와 호환되며, “MongoDB 호환 오픈소스 문서 데이터베이스를 구축”하는 것을 목표로 한다고 적고 있다. Amazon, Yugabyte 같은 다른 주요 DB 벤더들도 이 프로젝트에 참여한다. 얼핏 보면 이런 문구는 MongoDB가 FerretDB에 대해 주장하는 것과 비슷해 보인다.
Andy의 견해한 데이터베이스 회사가 다른 회사가 API를 복제했다며 소송을 건 사례는 찾지 못했다. 가장 가까운 예는 Oracle이 Android에서 Java API를 클린룸으로 복제한 Google을 소송한 일이다. 대법원은 결국 공정 이용을 근거로 Google 손을 들어줬고, 이 사건은 재구현이 법적으로 어떻게 취급되는지에 영향을 줬다.
이 소송이 재판까지 가면 어떻게 될지 모르겠다. 길거리에서 무작위로 뽑힌 배심원은 MongoDB 와이어 프로토콜의 세부를 이해 못할 수도 있지만, FerretDB의 원래 이름이 MangoDB였다는 건 이해할 것이다. 다른 회사 이름에서 글자 하나 바꾸고 고객을 빼앗으려 한 게 아니라고 배심원을 설득하기는 어려울 것이다. 게다가 그 이름 자체도 독창적이지 않다. 이미 /dev/null로 다 써버리는 농담 DBMS인 MangoDB가 있다.
그리고 데이터베이스 이름 얘기가 나왔으니 말인데, 마이크로소프트가 “DocumentDB”라는 이름을 고른 건 안타깝다. 이미 Amazon DocumentDB가 있고(참고로 Amazon도 MongoDB와 호환이지만 아마 그 대가를 지불할 것이다), InterSystems DocDB, Yugabyte DocDB도 있다. 마이크로소프트가 2016년에 “Cosmos DB”의 원래 이름으로도 DocumentDB를 썼다.
마지막으로, MongoDB 소장에는 자신들이 “‘비관계형’ 데이터베이스 개발을 개척했다”고 주장하는데, 이는 틀렸다. 최초의 범용 DBMS들은 관계형 모델이 아직 발명되지 않았기 때문에 비관계형이었다. GE의 Integrated Data Store(1964)는 네트워크 데이터 모델을 사용했고, IBM의 IMS(1966)는 계층형 데이터 모델을 사용했다. MongoDB가 최초의 문서 DBMS도 아니다. 그 타이틀은 1980년대 후반의 객체지향 DBMS들(예: Versant)이나 2000년대의 XML DBMS들(예: MarkLogic)에게 돌아간다. MongoDB는 이런 접근 중 압도적으로 가장 성공적이다(IMS를 제외하면).
파일 포맷은 지난 10년간 대체로 잠잠했던 데이터 시스템 영역이다. 2011년 Meta는 Hadoop용 컬럼 지향 포맷 RCFile을 공개했다. 2년 뒤 Meta는 RCFile을 다듬어 PAX 기반의 ORC(Optimized Record Columnar File)를 발표했다. ORC가 나온 한 달 후 Twitter와 Cloudera는 Parquet 첫 버전을 공개했다. 약 15년이 흐른 지금, Parquet은 지배적인 오픈소스 파일 포맷이다.
2025년에는 Parquet을 끌어내리려는 오픈소스 파일 포맷이 다섯 개나 나왔다:
이들은 2024년에 나온 다른 포맷들과 함께 경쟁에 합류했다:
SpiralDB는 Vortex를 리눅스 재단에 기부하고 다기관 스티어링 커미티를 구성한다고 발표하며 올해 가장 큰 주목을 받았다. 마이크로소프트는 2025년 말쯤 Amudai를 조용히 죽였고(혹은 적어도 클로즈드 소스로 전환했다). 나머지(FastLanes, F3, AnyBlox)는 학술 프로토타입이다. AnyBlox는 올해 VLDB 베스트 페이퍼를 수상했다.
이 신선한 경쟁은 Parquet 개발 커뮤니티에 불을 지펴, Parquet 기능을 현대화하도록 만들었다. Parquet PMC Chair인 Julien Le Dem의 컬럼 파일 포맷 지형에 대한 심층 기술 분석을 보라.
Andy의 견해Parquet의 핵심 문제는 포맷 자체에 내재한 게 아니다. 명세는 진화해왔고 앞으로도 그럴 수 있다. 누구도 조직들이 레거시 파일 수 페타바이트를 최신 Parquet 버전으로 업데이트하려고 재작성하리라 기대하지 않았다. 문제는 서로 다른 언어로 된 리더/라이터 라이브러리 구현이 너무 많고, 각 구현이 명세의 서로 다른 부분집합만 지원한다는 점이다. 우리가 야생에서 발견한 Paraquet(원문 그대로) 파일 분석에 따르면, 94%가 2013년의 v1 기능만 사용한다(생성 타임스탬프는 2020년 이후인 경우가 많은데도). 이 ‘최소 공통 분모’ 때문에 누군가 v2 기능으로 Parquet 파일을 만들면, 어떤 시스템이 제대로 읽을 수 있는 버전을 갖고 있는지 알기 어렵다.
나는 칭화대(Xinyu Zeng, Ruijun Meng, Huanchen Zhang), CMU(Martin Prammer, Jignesh Patel), 그리고 Wes McKinney 같은 뛰어난 사람들과 함께 F3 파일 포맷을 작업했다. 우리의 초점은 이 상호운용성 문제를 해결하는 것이다. 네이티브 디코더를 공유 오브젝트(Rust 크레이트)로 제공하고, 그 디코더의 WASM 임베디드 버전도 파일에 포함한다. 누군가 새로운 인코딩을 만들었는데 DBMS에 네이티브 구현이 없다면, Arrow 버퍼를 전달해 WASM 버전으로라도 데이터를 읽을 수 있다. 각 디코더는 단일 컬럼을 대상으로 하므로, DBMS는 한 파일에 대해 네이티브와 WASM 디코더를 섞어 쓸 수 있다. AnyBlox는 다른 접근을 취해, 파일 전체를 디코딩하는 단일 WASM 프로그램을 생성한다.
누가 파일 포맷 전쟁에서 이길지는 모르겠다. 다음 전장은 GPU 지원일 가능성이 크다. SpiralDB는 올바른 수를 두는 듯하지만, Parquet의 보편성을 넘기기는 쉽지 않을 것이다. 그리고 DuckLake가 Iceberg를 뒤흔들려는 얘기는 아예 하지도 않았다…
물론 이 주제가 나오면 누군가는 경쟁 표준에 대한 xkcd 만화를 꼭 올린다. 나도 이미 봤다. 다시는 이메일로 보내지 마라.
데이터베이스는 큰돈이다. 전부 훑어보자!
시장에 많은 움직임이 있었다. Pinecone은 9월에 CEO를 교체해 인수를 준비하는 듯했지만, 그 뒤 소식은 못 들었다. 실제로 일어난 인수는 다음과 같다:
DataStax → IBM Cassandra의 강자가 연초에 IBM에 인수됐고, 추정 30억 달러 규모다.
Quickwit → DataDog Lucene 대체제 Tantivy를 만든 선두 회사가 연초에 인수됐다. 좋은 소식은 Tantivy 개발이 계속된다는 점.
SDF → dbt dbt의 올해 Fusion 발표와 맞물린 좋은 인수다. DAG에서 더 엄격한 SQL 분석을 가능하게 한다.
Voyage.ai → MongoDB Mongo는 초기 단계 AI 회사를 인수해 클라우드 제품의 RAG 역량을 확장하려 했다. 내 최고 학생 중 하나가 발표 1주 전에 Voyage에 합류했는데, DB 회사에 안 간다고 “가족”을 거스르는 줄 알았더니 결국 DB 회사로 가게 됐다.
Neon → Databricks 이 PostgreSQL 회사에는 입찰 경쟁이 있었다고 한다. 하지만 Databricks는 군침 도는 10억 달러를 지불했다. Neon은 독립 서비스로 남아 있지만, Databricks는 생태계 안에서 이를 빠르게 Lakebase로 리브랜딩했다.
CrunchyData → Snowflake Snowflake가 Databricks에게 여름의 흥분을 다 빼앗길 리 없어서, 13년 된 PostgreSQL 회사 CrunchyData에 2억5천만 달러를 냈다. Crunchy는 최근 전 Citus 핵심 인력을 영입하며 DBaaS를 확장 중이었다. Snowflake는 2025년 12월 Postgres 서비스 퍼블릭 프리뷰를 발표했다.
Informatica → Salesforce 1990년대 구식 ETL 회사 Informatica가 Salesforce에 80억 달러에 인수됐다. 1999년 상장, 2015년 PE로 회귀, 2021년 재상장 이후다.
Couchbase → 사모펀드(PE) 솔직히 Couchbase가 2021년에 어떻게 상장했는지 이해 못 했다. MongoDB 덕을 본 건가? 몇 년 전 UC Irvine의 AsterixDB 프로젝트 구성요소를 도입하는 흥미로운 일을 했다.
Tecton → Databricks Tecton은 Databricks에 에이전트 구축을 위한 추가 툴링을 제공한다. 내 제자 중 한 명도 그 회사에 있었고, 이제 Databricks에 있다.
Tobiko Data → Fivetran 이 팀은 SQLMesh와 SQLglot이라는 유용한 도구 두 개를 만들었다. SQLMesh는 dbt에 맞설 만한 유일한 오픈소스 대안이다(아래 합병 참고). SQLglot은 휴리스틱 기반 옵티마이저를 지원하는 SQL 파서/디파서다. Fivetran+SQLglot과 dbt+SDF의 조합은 앞으로 몇 년간 이 분야에서 흥미로운 기술 판을 만들 것이다.
SingleStore → 사모펀드(PE) SingleStore를 인수한 PE인 Vector Capital은 DB 회사 운영 경험이 있다. 2020년에 XML DB MarkLogic을 인수해 2023년에 Progress에 되팔았다.
Codership → MariaDB 2024년 PE에 인수된 뒤, MariaDB Corporation은 올해 인수전에 나섰다. 첫 번째는 MariaDB용 동기식 복제 스케일아웃 미들웨어 Galera Cluster를 만드는 회사다. 2023년 MariaDB 쓰레기불 개요를 보라.
SkySQL → MariaDB 두 번째 MariaDB 인수다. 혼란 방지를 위해 정리하면: MariaDB를 후원하던 원래 상용 회사는 2010년에 “SkySQL Corporation”이었고 2014년에 “MariaDB Corporation”으로 이름을 바꿨다. 2020년에 MariaDB Corporation은 SkySQL이라는 MariaDB DBaaS를 출시했다. 하지만 현금이 말라가자 2023년에 SkySQL Inc.를 분사해 독립 회사로 만들었다. 그리고 2025년에 MariaDB Corporation은 다시 SkySQL Inc.를 재인수했다. 올해 내 DB 빙고 카드에는 없던 수다.
Crystal DBA → Temporal 자동 DB 최적화 도구 회사가 Temporal로 갔다. Crystal 창업자이자 Berkeley DB 그룹 동문 Johann Schleier-Smith이 잘 지내는 듯해 기쁘다.
HeavyDB → Nvidia (구 OmniSci, 구 MapD) 2013년 출시된 초기 GPU 가속 DB 중 하나다. 공식 종료 발표는 못 찾았고 M&A 회사의 성사 목록 정도만 있다. 그런데 Nvidia와 DB 연구 협업 미팅을 했더니 HeavyDB 지인들이 나타났다.
DGraph → Istari Digital Dgraph는 2023년에 Hypermode에 인수됐었다. Istari는 Hypermode 전체가 아니라 Dgraph만 산 듯하다(또는 나머지를 버린 듯). 아직도 Dgraph를 적극 쓰는 사람을 만나본 적이 없다.
DataChat → Mews 위스콘신대 출신이자 지금은 CMU-DB 교수인 Jignesh Patel이 만든 초기 “DB와 채팅” 회사 중 하나다. 그런데 유럽의 호텔 관리 SaaS에 인수됐다. 이게 무슨 뜻인지는 각자 해석하라.
Datometry → Snowflake Datometry는 레거시 SQL 방언(예: Teradata)을 최신 OLAP 시스템으로 자동 변환하는 위험한 문제를 수년간 해왔다. Snowflake는 마이그레이션 툴링 강화를 위해 이들을 인수했다. 더 알고 싶으면 Datometry의 2020년 CMU-DB 기술 강연을 보라.
LibreChat → ClickHouse Snowflake가 Datometry를 산 것과 비슷하게, ClickHouse의 이번 인수도 고성능 범용 OLAP 엔진의 개발자 경험 개선을 보여주는 좋은 사례다.
Mooncake → Databricks Neon을 인수한 뒤 Databricks는 PostgreSQL이 Apache Iceberg 데이터를 읽고 쓰게 하기 위해 Mooncake를 샀다. 자세한 건 2025년 11월 CMU-DB 강연을 보라.
Confluent → IBM 이건 풀뿌리 오픈소스 프로젝트로 회사를 만드는 전형이다. Kafka는 2011년 Linkedin에서 시작됐고, Confluent는 2014년에 분사 스타트업으로 나왔다. 2021년(7년 뒤) IPO를 했고, IBM이 큰돈을 써서 가져갔다. DataStax처럼, IBM이 보통 인수 기업에 하는 짓을 Confluent에도 할지, 아니면 RedHat처럼 자율성을 유지할지는 두고 봐야 한다.
Gel → Vercel 예전 이름은 EdgeDB였고, PostgreSQL 위에 DSL을 제공하던 회사가 연말에 Vercel에 인수됐다.
Kuzu → ??? 워털루대에서 나온 임베디드 그래프 DBMS가 2025년에 익명 회사에 인수됐다. 이후 KuzuDB 회사는 오픈소스 프로젝트를 포기한다고 발표했다. LadybugDB는 Kuzu 코드를 포크해 유지하려는 시도다.
2025년 10월, Fivetran과 dbt Labs가 주식 교환 방식으로 합병해 단일 회사를 만든다는 예상 밖 소식이 나왔다.
내가 기억하는 마지막 데이터베이스 분야 합병은 2019년 Cloudera와 Hortonworks였다. 하지만 그건 하둡으로 시장 관련성을 찾지 못하던 두 회사가 주방에서 약한 키가 밟히듯 합쳐본 것에 불과했다(스포일러: 못 찾았다). 2022년 MariaDB Corporation이 SPAC으로 Angel Pond Holdings Corporation과 합병한 것도 기술적으로는 합병이지만, 그건 IPO를 백도어로 하기 위한 것이었고 투자자에게 좋은 결말은 아니었다. Fivetran+dbt 합병은 (그리고 더 낫다) 이 둘과 다르다. 서로 보완적인 기술 회사들이 결합해 ETL 강자가 되어, 가까운 미래의 제대로 된 IPO를 준비하는 것이다.
내가 놓쳤거나 공개되지 않은 걸 제외하면, 올해는 초기 단계 DB 스타트업 펀딩이 그리 많지 않았다. 벡터 DB에 대한 버즈는 잦아들었고, VC들은 LLM 회사에만 수표를 쓴다.
올해부터는 DB 회사/시스템 이름 바꾸는 사례도 카테고리로 넣었다.
HarperDB → Harper JSON DB 회사가 애플리케이션 플랫폼 포지셔닝을 강조하려고 “DB”를 뺐다(Convex, Heroku 같은 느낌). Harper 사람들은 좋다. 다만 2021년 CMU-DB 강연에서는 내가 들어본 DBMS 아이디어 중 최악을 제안했었다. 다행히 그게 얼마나 나쁜지 깨닫고 버린 뒤 LMDB로 전환했다.
EdgeDB → Gel “Edge”는 엣지 디바이스/서비스용 DB처럼 들리니(예: Fly.io) 현명한 결정이다. 다만 “Gel”이 프로젝트의 상위 목표를 잘 전달하는지는 모르겠다. CMU 박사 동문이 한 2025년 Gel 쿼리 언어(CMU-DB 강연)도 보라(여전히 EdgeQL이라 부르지만).
Timescale → TigerData DB 회사가 자사 핵심 DB 제품과 구분하려고 회사 이름을 바꾸는 드문 사례다. 보통은 회사가 DB 이름을 따르도록 바뀐다(예: “Relational Software, Inc.” → “Oracle Systems Corporation”, “10gen, Inc.” → “MongoDB, Inc.”). 하지만 “특화된 시계열 DBMS”라는 인식을 벗고, 일반 애플리케이션을 위한 “개선된 PostgreSQL”로 보이려면 이해가 된다. 전자가 시장이 훨씬 작기 때문이다.
고백하자면, 나는 이 실패한 스타트업 중 두 곳에서 기술 자문을 했다. 지금 내 자문 성공률은 형편없다. 나는 Splice Machine에도 자문했지만 그들은 2021년에 문을 닫았다. 변명하자면, 나는 기술 아이디어만 논의하고 비즈니스 전략은 다루지 않는다. 그리고 Fauna에는 SQL을 넣으라고 조언했지만, 듣지 않았다.
Fauna Dan Abadi의 결정론적 동시성 제어 연구에 기반한 흥미로운 분산 DBMS다. NoSQL 열기가 식고 Spanner가 트랜잭션을 다시 멋있게 만들던 시기에 강한 일관성 트랜잭션을 제공했다. 하지만 독자 쿼리 언어를 갖고 GraphQL에 크게 베팅했다.
PostgresML 아이디어는 자명해 보였다: PostgreSQL 안에서 ML/AI 연산을 돌리자. 문제는 사람들이 기존 DB를 그들의 호스티드 플랫폼으로 옮기도록 설득하는 것이었다. 그들은 DB 트래픽을 미러링하는 프록시로 pgCat을 밀었다. 공동창업자 한 명은 Anthropic에 갔고, 다른 한 명은 pgDog라는 새 프록시 프로젝트를 만들었다.
Derby 1997년으로 거슬러 올라가는, Java로 작성된 초기 DBMS 중 하나다(원래는 “Java DB” 혹은 “JBMS”). IBM이 2000년대에 Apache 재단에 기부했고 Derby로 이름이 바뀌었다. 2025년 10월, 프로젝트는 더 이상 유지보수하는 사람이 없다며 “read-only mode”로 들어간다고 발표했다.
Hydra Postgres 안에 DuckDB를 넣는 스타트업에 대해 공식 발표는 없지만, 공동창업자와 직원들이 다른 회사로 흩어졌다.
MyScaleDB ClickHouse 포크로, 벡터 검색과 Tantivy 기반 전문 검색 인덱싱을 추가했다. 2025년 5월에 종료를 발표했다.
Voltron Data DB 업계의 슈퍼그룹이 될 예정이었다. Run the Jewels 같은 강자들의 팀이라고 생각하면 된다. Nvidia Rapids의 최고 엔지니어, Apache Arrow와 Python Pandas 창시자, BlazingSQL의 페루 GPU 마법사들까지. 거기에 미래의 Intel CEO(이자 CMU 이사회 멤버)가 포함된 최상급 VC들로부터 $1억1천만 달러를 받았다. GPU 가속 DB(Theseus)를 만들었지만 제때 출시하지 못했다.
마지막으로, 기업은 아니지만 IBM Research Almaden의 폐쇄도 언급하지 않을 수 없다. IBM은 1986년에 이곳을 세웠고 수십 년간 DB 연구의 성지였다. 나는 2013년에 Almaden에서 면접을 봤고 경치가 아름다웠다. IBM Research DB 그룹은 예전의 위상은 아니지만, 이 성지 출신들의 목록은 여전히 압도적이다: Rakesh Agrawal, Donald Chamberlin, Ronald Fagin, Laura Haas, Mohan, Pat Selinger, Moshe Vardi, Jennifer Widom, Guy Lohman.
업데이트 2026-01-05: Gel이 2025년 12월에 Vercel에 인수된 사실을 놓쳤다. [출처]
Andy의 견해누군가 내가 DB 개발 회사가 얼마나 펀딩을 받았는지로 DB 품질을 판단한다고 주장했는데, 당연히 사실이 아니다. 나는 이 사건들을 추적하는 이유가, DB 연구판이 혼잡하고 에너지가 높기 때문이다. 나는 다른 대학의 학자들과 “경쟁”할 뿐 아니라, 대기업과 스타트업도 흥미로운 시스템을 계속 내놓아서 따라가야 한다. 산업 연구소는 예전만 못하지만, Microsoft Research만은 여전히 공격적으로 인재를 채용하며 놀라운 일을 한다.
나는 2022년에 2025년에 많은 DB 회사가 문을 닫을 거라고 예측했다. 올해가 예년보다 폐업이 많긴 했지만, 내가 예상한 규모는 아니었다.
Voltron의 죽음과 HeavyDB의 반-어퀴하이어는 GPU 가속 DB의 비현실성이라는 흐름을 이어가는 것처럼 보인다. Kinetica는 수년간 정부 계약으로 버텼고 Sqream도 아직 살아있는 듯하다. 하지만 이들은 여전히 니치이고, CPU 기반 DBMS의 지배에 유의미한 금을 낸 곳은 없다. 누구/무엇인지는 말 못 하지만, 2026년에 벤더들로부터 큰 GPU 가속 DB 발표가 있을 것이다. 또한 이는 OLAP 엔진의 상품화(commoditization)를 보여준다. 요즘 시스템은 너무 빨라져서 저수준 연산(스캔, 조인)에서 성능 차이가 미미하고, 차별화 요소는 사용자 경험과 옵티마이저가 생성하는 쿼리 플랜 품질이 된다.
Couchbase와 SingleStore의 PE 인수는 DB 산업에서 새로운 추세를 시사할 수도 있다. PE 인수는 예전에도 있었지만, 눈에 띄는 건 최근에 몰려 있다: (1) 2020년 MarkLogic, (2) 2021년 Cloudera, (3) 2023년 MariaDB. 2020년 이전에 찾을 수 있는 건 2007년 SolidDB와 2015년 Informatica 정도다. PE 인수는, 성장이 정체된 DB 회사가 유지보수 비용을 영원히 짜내는 지주회사(Actian, Rocket)에 팔리는 흐름을 대체할지도 모른다. Oracle조차 30년 전 인수한 RDB/VMS에서 아직도 돈을 번다!
마지막으로 Nikita Shamgunov에게 경의를. 내가 아는 한, 그는 두 개의 DB 회사(SingleStore, Neon)를 공동창업했고, 둘 다 같은 해에 인수된 유일한 사람이다. DMX(RIP)가 같은 해 #1 앨범 두 장(It’s Dark and Hell Is Hot, Flesh of My Flesh)을 냈던 것처럼, Nikita의 기록은 당분간 깨지지 않을 것 같다.
데이터베이스 OG인 Larry Ellison에게는 말 그대로 대박의 해였다. 그는 81세가 되었고, 한 해 동안 대부분의 사람들이 평생에 이룰 만한 것보다 많은 일을 해냈다. 시간순으로 정리하겠다.
Larry는 연초에 세계 3위 부자였다. Mark Zuckerberg보다 덜 부자라는 생각이 그를 밤에 잠 못 들게 했다. 어떤 사람들은 Larry의 불면이 유명한 영국 펍을 산 뒤 파이를 더 먹게 된 식단 변화 때문이라고 했지만, Larry의 “veg-aquarian” 식단은 30년째 바뀌지 않았다. 그러다 2025년 4월, Larry가 세계 2위 부자가 됐다는 소식이 나왔다. 잠은 조금 나아졌지만, 아직 만족스럽진 않았다. 삶에서 그를 스트레스 주는 일이 여전히 많았기 때문이다. 예를 들면 Larry는 마침내 희귀하고 반쯤 도로 주행 가능한 McLaren F1 슈퍼카를 팔기로 했다(글러브박스에 오너 매뉴얼 원본 포함).
2025년 7월, Larry는 13년 동안 세 번째 트윗을 남겼다(애호가들 사이에서는 “#3”으로 불린다). 내용은 Oxford 근처에 Larry가 세운 Ellison Institute of Technology(EIT) 업데이트였다. EIT라는 이름과 Oxford 연계 때문에 Stanford의 SRI나 CMU의 SEI 같은 순수 비영리 연구기관처럼 들리지만, 사실은 캘리포니아 기반 LLC가 소유한 일련의 영리 회사들을 묶는 우산 조직이다. 물론 어떤 괴짜들은 #3에 블록체인 기반 냉동 보존이나 상온 초전도체를 약속하며 답글을 달았는데, Larry는 그런 건 무시한다고 내게 말했다. 반면 이 사람처럼 제대로 이해한 사람도 있다.
올해(어쩌면 세기) 최대의 DB 뉴스는 9월 10일 수요일, 미 동부 시간 오후 3시쯤 우리를 덮쳤다. 수십 년을 기다린 끝에 Larry Joseph Ellison이 마침내 세계 1위 부자가 된 것이다. 그날 아침 $ORCL 주가는 40% 뛰었고, Larry가 회사의 40%를 여전히 보유하고 있어 추정 자산은 $3,930억 달러에 달했다. 이는 단지 세계 최고 부자가 됐다는 것뿐 아니라, 인류 역사상 가장 부유한 개인이 됐다는 뜻이다. 인플레이션을 반영한 John D. Rockefeller와 Andrew Carnegie(CMU의 ‘C’)의 최고 순자산은 각각 $3,400억과 $3,100억 달러에 불과했다.
Larry의 등극 외에도, Oracle은 TikTok을 통제하는 미국 회사 인수에 관여했고, Larry는 (네 번째 결혼에서 낳은 아들이 통제하는) Paramount를 후원해 Warner Bros 인수 입찰을 돕고 있다. 미국 대통령은 Larry가 Paramount의 최대 주주라는 이유로, Larry에게 CNN 뉴스 부문을 장악하라고까지 말했다.
Andy의 견해어디서부터 시작해야 할지 모르겠다. Larry Ellison이 DB 덕분에 세계 최고 부자가 됐다는 걸 알았을 때, 나는 마침내 우리 삶에 긍정적인 일이 생겼다며 용기를 얻었다. Oracle 주가가 전통적 소프트웨어 비즈니스가 아니라 AI 데이터센터를 위한 요란한 딜로 인위적으로 펌핑됐든, 상관없다. 그가 두 달 만에 개인적으로 $1,300억을 잃고 순위에서 내려갔든, 상관없다. 그건 너와 내가 월급을 도박 코인에 날리는 것과 비슷하다. 조금 아프긴 하고, Taco Bell에서 가져온 유통기한 지난 핫소스와 섞은 쌀과 콩을 2주 먹어야 할지 몰라도, 결국 괜찮아진다.
어떤 사람들은 Larry가 평범한 사람들과 동떨어져 있다고 주장한다. 혹은 DB와 직접 관련 없는 일에 관여하면서 길을 잃었다고 말한다. 예컨대 하와이의 로봇 농장이 파운드당 24달러(€41/kg)짜리 상추를 판다거나, 81세 남성이 자연 금발일 리 없다거나.
진실은, Larry Ellison은 엔터프라이즈 DB 세계, 요트 레이싱, 테크브로 웰니스 스파까지 정복했다. 다음 단계가 공항에서 매일 수천 명이 보는 케이블 TV 채널을 접수하는 것인 건 당연하다. 내가 Larry와 이야기할 때마다, 그는 사람들이 뭐라 하든 신경 쓰지 않는다는 걸 분명히 한다. 그는 팬들이 자신을 사랑한다는 걸 알고, (새) 아내도 자신을 사랑한다는 걸 안다. 결국 중요한 건 그거뿐이다.
마무리하며 몇 가지 짧은 샤우트아웃과 조언을 남긴다. 먼저 PT에게: 수감 중에도 Turso로 DB 실력을 날카롭게 유지해줘서 고맙다(밖에서 보자). JT에게는 직장을 잃은 것에 애도를 보낸다. KevoDB DB ‘바람 상대’를 가둬버린 죄(?)로 말이다. 그리고 테스트용으로는 반드시 가짜 데이터만 넣고, 1억7,500만 달러에 팔아먹었다가 7년형을 받게 되는 일은 하지 마라.
내 박사과정 학생들과 나는 새 스타트업도 시작했다. 곧 더 많은 이야기를 하길 바란다. 워드는 본드다.
