ハクソク

世界を動かす技術を、日本語で。

2025年のデータベース：振り返り

102日前原文(www.cs.cmu.edu)

概要

  • 2025年のデータベース業界の主要トレンドと出来事を総括
  • PostgreSQLの支配力がさらに強化、関連企業やサービスの動向
  • 分散型PostgreSQLプロジェクトの登場と各社の戦略
  • AnthropicのModel Context Protocol（MCP）の普及と業界への影響
  • MCPサーバーやデータベースブランチ機能の活用状況

2025年のデータベース業界総括

  • 2025年もデータベース分野で多くの画期的な出来事が発生
  • Vibe codingの流行語化やWu-Tang Clanのタイムカプセルプロジェクトなど、業界外からの影響も話題
  • Databricksが上場せずに2度の大型資金調達を実施、SnowflakeもCrunchyDataを2.5億ドルで買収
  • Redis Ltd.がライセンスを再変更、SurrealDBのベンチマーク不正、HydraやPostgresMLの事業終了
  • 記事で取り上げる内容は、筆者が注目した出来事に限定、全てのシステムや企業を網羅できない点に注意喚起

PostgreSQLの支配力拡大

  • PostgreSQLは2025年も業界の中心的存在、v18で非同期I/Oストレージやスキップスキャン等を導入
  • 他DBMSですでに実装済みの機能も多いが、PostgreSQL関連企業やプロジェクトの活発さが注目点
  • DatabricksがNeonを10億ドルで買収、SnowflakeはCrunchyDataを2.5億ドルで取得、MicrosoftはHorizonDBを新規投入
    • NeonやHorizonDBはAuroraのアーキテクチャを踏襲
    • SnowflakeはCrunchy Bridgeベースで標準PostgreSQLアーキテクチャ
  • 分散型（スケールアウト）PostgreSQLプロジェクトが新たに発表
    • SupabaseがVitess共同創業者Suguを迎え、Multigresプロジェクトを始動
    • PlanetScaleはNeki（Vitess for PostgreSQL）を発表
  • 主要クラウドベンダーが揃ってPostgreSQLサービスを展開
    • Amazon（Aurora）、Google（AlloyDB）、ServiceNow（RaptorDB）、IBM、Oracle、Microsoft（HorizonDB）
  • 独立系（ISV）のPostgreSQL DBaaSも存在
    • Supabase、YugabyteDB、TigerData（旧TimeScale）、PlanetScale、Xata、PgEdge、Nileなど
    • Temboは2025年にDBaaSを終了し、データベースチューニングエージェントへ転換
    • Hydra、PostgresMLは2025年に事業終了
  • PostgreSQL互換フロントエンドを持つが、バックエンドが異なるシステムも存在
    • CockroachDB、CedarDB、Google Spannerなど
  • PostgreSQL M&Aの今後は不透明、業界再編の可能性
    • EnterpriseDBの動向や、過去のOLAP業界の買収劇との類似性
    • 分散PostgreSQLの歴史的経緯（Greenplum、ParAccel、Citus、Postgres-XC/XL、YugabyteDB等）
    • Microsoftの製品名の混乱（Citus、Cosmos DB、Flexible Server等）

MCP（Model Context Protocol）の普及

  • 2025年はほぼ全てのDBMSがAnthropicのMCP対応を実現
    • MCPはLLMと外部データソースの連携を標準化するJSON-RPCインターフェース
    • サーバーがDBMSの前段でツールやデータ、アクションを提供
    • クライアント（ClaudeやChatGPT等）がMCP経由でDB操作や管理コマンドを実行
  • OpenAIが2025年3月にMCPサポートを発表し、急速に普及
    • OLAP（ClickHouse、Snowflake等）、SQL（YugabyteDB、Oracle等）、NoSQL（MongoDB、Redis等）でMCPサーバーが登場
    • Postgres公式MCPサーバーは存在せず、各DBaaSが独自実装（Timescale、Supabase、Xata等）
    • クラウドベンダーはマルチDB対応MCPサーバーを提供
  • MCPサーバーは単一DBへのリクエストのみ対応、アプリ側での統合処理が必要
  • サードパーティやコミュニティによるMCPサーバー実装も多数
    • DBHub等、複数DB対応のMCPサーバーも登場
  • データベースブランチ機能がエージェント用途で活躍
    • Neonではエージェント作成DBの8割がブランチ機能を利用
    • Neonは設計段階からブランチをサポート、他社も追随傾向

今後の展望と業界動向

  • PostgreSQLを巡る競争激化と分散型アーキテクチャの進化
  • MCPを中心としたLLM連携の標準化が進展
  • クラウドベンダーと独立系DBaaSの差別化、M&A動向に注目
  • 業界内の論争や競争激化（例：PlanetScale vs Neon/Timescale）も今後の見どころ

Hackerたちの意見

PavloがMCPのセキュリティについて懐疑的なのは正しいと思う。MCPの哲学は、モデルのためにコンテキストの可用性を最大化することに重点を置いているみたいだけど、それは「最小権限の原則」と真逆だよね。コンテキスト用に設計されたプロトコルを通じてデータベースを公開すると、単にデータをさらけ出すだけじゃなくて、曖昧さに弱いエンティティにスキーマの複雑さもさらけ出してしまう。なんか、SQLインジェクションを再発明してる気がするけど、今回は悪意のあるユーザーじゃなくて、システム自身の幻覚からのインジェクションって感じ。
└
完全に同意だね、データベースへの無制限アクセスは危険だよ。LLMはステートレスだから、インジェクションリスクを減らす方法があると思う。LLMに入るコンテキストの出所や信頼性を監視して、状態に影響を与えるMCBアクションが危険かどうかを判断できるから。Simon Willisonの致命的トライフェクターフレームワークに基づいた仕組みを実装したんだ。これはMCPゲートウェイとして、コンテキストに入るものを監視するものだよ。このMCPセキュリティへのアプローチについてフィードバックがあれば教えてね。Pavloが投稿で話してるアプローチほどエレガントではないけど、技術が成熟するまでの良い応急処置だと思ってる。https://github.com/Edison-Watch/open-edison
└
そのトレードオフがそんなにワクワクするものだったから、自分たちの原則を捨てちゃったの？それとも、みんなレミングスなの？編集：ちょっと皮肉っぽくなっちゃってごめん。これは「速く動いて壊す」っていう精神が出てきたって考えたいな。
著者はedgeDbからgelへの名前変更について触れてるね。でも、Acquisitionsの状況にも追加されたかもしれない。gelはvercelに参加したみたいだよ。[1] 1. https://www.geldata.com/blog/gel-joins-vercel
└
まじで今日が台無しになった。投稿のせいで、gelがもう終わったみたいに聞こえる。Vercelの投稿もあんまり希望が持てないし。[1] gelのリポジトリの最終コミットは2週間前だったよ。[1] https://vercel.com/blog/investing-in-the-python-ecosystem
└
これを見つけてくれてありがとう。更新したよ: https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-re... 自動でこれを追跡する方法を考えないと。
ちょっと話がそれるけど、CMU DBグループに詳しくないなら、彼らの独特な教授スタイルをチェックしてみるといいかも。[1] 彼らのギャングスタ風のイントロや[2] 講義前のDJセットが大好きなんだ。あと、誰かが床で寝てる背景で講義してる動画もあった気がするけど、今はその動画が見つからない。文脈やAndyの経歴についてはあまりわからないから、後で調べてみるつもり。今はもっと興味が湧いてきた。[1] youtube.com/results?search_query=cmu+database [2] youtu.be/dSxV5Sob5V8 [3] youtu.be/7NPIENPr-zk?t=85
└
確かに、wutangのタイムカプセルについての部分を読んでめっちゃ嬉しかった。OPはwu-tangとヒップホップ全般のファンだね。シェアしてくれたイントロ、最高だよ！
└
彼の講義にはDJがいるんだ。いつも「hit it!」って言って終わるよ。[音楽スタート]
データベースについての私の視点から見ると、2025年には2つのトレンドが続いてるね。1: すべてをSQLiteに移行 2: 主にJSONフィールドを使用 この2つは数年前から始まって、2025年に加速した感じ。SQLiteは本当に扱いやすくて、デーモンなし、データベースごとに1ファイル、値ごとに1タイプのアプローチがいいよね。JSONの矢印関数を使うと、柔軟なJSONデータを扱うのが楽しくなる。
└
私の視点では、すべてがDuckDBだね。データベースごとに1ファイル、複数の取り込みフォーマット、全文検索、S3サポート、Parquetファイルサポート、カラムストレージ、完全に型付けされてる。JavaScriptでフルSQLを使うためのWASMバージョンもあるよ。
└
無知をお許しくださいだけど、数年前にはSQLiteを本番環境で使うことはないっていうのが一般的な考えだったよね？その考え方は変わったのかな？
└
マルチユーザーじゃないバックエンドデータベースとして、書き込みを行うウェブ接続は現実的にどれくらい処理できるの？書き込みが小さいとして、たとえば100行以上とか？大きなユースケースに対する緩和策はあるのかな？事前にありがとう！
└
SQLiteについての話はよく見るけど、実際に使ってる人いるのかな？それとも、ただマーケティングが上手なだけ？
└
可能なときはSQLite、必要なときはPostgreSQL（拡張も含めて）、ローカルや趣味のデータ分析にはDuckDB、企業のビジネスインテリジェンスにはBigQuery（TBやPB単位）を使うかな。
著者が「全てのデータベースを見る時間がない」って言ってるけど、最近のレビューには不変データベースや二重時間データベースについて全然触れられてないよね。正直、これって盲点じゃない？このカテゴリのデータベースはフィンテックみたいな業界にはめちゃくちゃ合ってると思う。候補が二つあるよ。 https://xtdb.com/blog/launching-xtdb-v2 (2025) https://blog.datomic.com/2023/04/datomic-is-free.html (2023)
└
なんでフィンテックに特化してるの？
└
xtdbやdatomicがSPARQLのグラフトラバーサルに追いつけないから、みんなトリプルストアに時間性や不変性を無理やり追加してるの見かける。時間旅行にネイティブで対応したトリプルストアが出てくるのを期待してるんだ。
└
不変データベースの利点に気づくのが遅い人が多いけど、少しずつ進んでるよ。監査可能性だけじゃなくて、不変データベースは書き込み中でも同時に読み込みができたり、データ構造の高速クローンやトランザクションの高速取り消しもできるんだ。君が言ったのは大規模なバックエンドデータベースだけど、私は「不変SQLite」に取り組んでるよ…埋め込まれてライブラリとして動作する単一ファイルの不変データベースだよ。: https://github.com/radarroark/xitdb-java
あの記事にSQLiteのことが全く触れられてないなんて信じられないんだけど？？
└
> その記事にSQLiteのことが全然書かれてないなんて信じられない ?? https://www.cs.cmu.edu/~pavlo/blog/2026/01/2025-databases-re...
OracleやMS SQL Serverの話がほとんど出てこないね。これらは世界で最も使われているデータベースの1位と3位だって言われてるのに。https://db-engines.com/en/ranking
└
最初にOracleが言及されて、Postgresの「支配力」について語ってるけど、その新機能はもう25年近くOracleにあるって認めてるよね。彼が言ってる「支配力」って、スタートアップが投資家からいくらお金を集めてるかの話だけで、技術的なことじゃないんだよね。それに、最後にはいつものようにLarry Ellisonについてのセクションがあるし。
DuckDBの話が出てこないの？意外だね。
└
ここでも同じ驚きだね。でも実際には、コミュニティはDuckDBを伝統的なデータベースというよりもクライアントサイドのツールとして話すことが多いみたい。
> 「PostgreSQLの支配力は続く」 著者はユーザーベースよりもデータベースの機能に焦点を当てているみたいだね。オンラインで見つけられる指標はどれもMySQL/MariaDBがPostgreSQLより人気だと言ってる。PostgreSQLは「良い」みたいだけど（機能が多くて、標準に準拠してる）、MySQL/MariaDBは多くの人にとって問題なく動いてる。私、バブルの中にいるのかな？
└
著者はお金の流れを基に観察しているんじゃないかな。PostgreSQL関連のスタートアップやビジネスには、かなりの投資が集まってるし。
Anybloxってファイルフォーマットって言えるのかな？プロジェクトの理解からすると、他のファイルフォーマットのデコーダーに過ぎないと思うんだけど、MxN問題を解決するための。