Databricks、サーバーレスPostgresの専門企業Neonを買収

• Databricksは、開発者中心のサーバーレスPostgresを提供するNeonの買収に合意
• Neonは、ストレージとコンピュートの分離アーキテクチャにより、開発者とAIシステムに最適化されたサーバーレスデータベースプラットフォームを提供
• Neonの導入により、AIエージェントが生成するデータベースの比率が30%から80%以上へと急成長
• DatabricksとNeonは、オープンソースの思想とインフラ革新のDNAを共有
• 買収後も、Neonプラットフォームのサポートと将来志向のロードマップはDatabricksのリソースで強化される予定

---

買収発表とその意義

• Databricksは、開発者中心のサーバーレスPostgresを提供するNeonの買収に合意
• Neonの共同創業者たちは、ストレージとコンピュートを完全に分離した構造でPostgresを設計できる、世界でも数少ない専門家
• このチームは、AI時代における大規模な開発者支援のためのサーバーレスPostgresプラットフォームの提供に注力してきた

Postgresベースの革新ミッション

• Neonの共同創業者たちは約4年前、旧来的なデータベース構造を革新しようと集結
• 中核目標は以下の通り
  • Postgresの事実上の標準化を見越し、サーバーレスプラットフォームのビジョンを策定
  • 開発者が数秒で新しいインスタンスを作成できるよう、速度を重視
  • データベースの自動スケーリングと作業の簡素化によって、過剰・過少プロビジョニングの懸念解消を目指す
  • 即時のブランチ作成とフォーク対応により、データベースのテストや実験を容易にする
• Neonチームは、ストレージとコンピュートを独立してスケール可能なアーキテクチャを構築し、これらの目標を達成
• リリース後、開発者たちは速度、シンプルさ、そしてGit方式のブランチ/フォーク機能を高く評価

AIエージェント時代の変化

• NeonのGA以降、AIエージェントが全DB生成の30%を占めていたが、最近では80%以上に増加
• AIエージェントが開発者と似た要件を持つようになった
• Neonの強みは次の通り
  • Postgresオープンソースエコシステム: 最新のLLMはPostgresデータで学習されており、AIエージェントはNeonの利用に習熟している
  • 高速性: 人間よりも速い速度が求められ、超高速のインスタンスプロビジョニングが必須
  • 柔軟なスケーリングと価格: 分離されたサーバーレス構造により超低コストを実現し、多数のAIエージェントを支援可能
  • ブランチとフォーク: AIエージェントの変化に富んだ試行のため、実験や検証が容易になる

DatabricksとNeonの共有DNA

• 創業者のNikita Shamgunov、Heikki Linnakangas、Stas Kelvichは、業界で著名なDB技術の専門家
• SingleStore、Postgresコミッターなど、それぞれ豊富な経験と独創性を備える
• DatabricksとNeonはいずれも、インフラ層における先端技術革新とオープンソースの価値を重視
• Apache SparkとPostgresはいずれも、UC Berkeleyで始まったオープンソースプロジェクトというつながりがある

今後のビジョンとユーザーへの利点

• OLTPデータベース市場（約1000億ドル規模）は、現在も数十年前の製品が中心
• いまこそ開発者とAIエージェントが革新を主導する時
• DatabricksとNeonは、最高レベルで開発者フレンドリーかつAIエージェントフレンドリーなDBプラットフォームを目指す
• 既存のNeon顧客とパートナーは、継続的なサポートと革新、そしてロードマップの実現を期待できる
• Databricksのリソースを通じて、プラットフォーム強化と安定成長が実現される予定
• Data + AI Summit（サンフランシスコ、6月9〜12日）で今後のビジョンを詳しく共有する予定

[GN⁺]

Hacker Newsのコメント

• データウェアハウジングはオープンソースのおかげで急速にコモディティ化していると思う。知っている会社では2ペタバイト超のデータをClouderaに保存していたが、クラウド（Databricks）へ移行せず、Iceberg、Trino、Supersetで独自の分析プラットフォームを構築してコストを5分の1に抑えた。エンタープライズ級のk8sオペレーターは今や十分に良く、オンプレミスS3も優秀。128 CPUと1TBメモリを備えたサーバーのような優れたハードウェアやネットワーキングも利用可能。Trinoだけでなく、StarRocksやClickHouseもエンタープライズ級のk8s Helmチャート／オペレーターを提供している。Databricksの企業価値600億ドルは彼ら自身の重荷だ。その価格を正当化しなければならず、彼らの中核ビジネス自体もコモディティ化している。Neonは、運用向け（行指向）DBがなかった製品群の空白を埋めるものだ
  • エンタープライズの立場ではコモディティ化ではない。前職では、オープンソースソフトウェアや10年後に存在しないかもしれない会社、あるいはデータを自社テナント外に置く企業は許可されていなかった。「お問い合わせください」型の価格設定をむしろ歓迎していたし、データプラットフォームをこれ以上気にしなくてよいという点で、Databricks導入は自分の3大成果のひとつだった。新しいプラットフォーム導入時のリスクは大きすぎて、（どんなオープンソースプロジェクトでも）信頼できなかった。一度スタートアップのソリューションを導入したことがあるが、MongoDBを使っていて運用チームの力量が足りなかったため、学習する代わりにAtlasのようなサポート完備のサービスを契約した。慣れていないAzureファイアウォールではなく、使い慣れたファイアウォールだけを使い、各種契約も進めた。採用人数を減らし、連絡窓口も一本化し、業務効率を実現した。スタートアップのライセンスは年5〜10Kドルでも、サポートには40Kドルなどはるかに多くの費用がかかる。スタートアップとエンタープライズはまったく別世界だ
  • オープンソースのStarRocksをk8sオペレーターで使い、テラバイト級データの顧客分析をしているが、自分の環境ではDatabricksはほとんど不要だと感じる
  • ClickHouseをここ数年、問題なく使っている。機能の幅が広く、信頼できるデータベースだ。external dictionary機能のおかげで、Postgres、Redisなど他のデータストアとの連携がしやすい
  • Kubernetesオペレーターを基盤としたオープンソースCloudera代替を探しているなら、stackable.techを5年間開発してきた。オンプレミスのオープンソースS3は問題がある。MinIOは勧めないし、それ以外はエンタープライズ対応可能なソリューションがほとんど空白だ
  • データウェアハウジングは数十年前からコモディティ化していた。価格と性能指標の歴史は長いが、SnowBricks製品はそれに合致していない。押し売りかソフトセルかの違いでしかない
  • なぜDatabricksから運用DBを買う必要があるのかわからない。市場価値を維持するためのDatabricksの悪戦苦闘にしか見えない
  • もしDatabricksが単にrow DBを必要としていただけなら、自前でPostgresを構築していただろう。Neonにこれほど多くの金を払ったのは、Neonの「独立してスケール可能なストレージとコンピュート」のような何か特別な点を欲したというシグナルだ
  • ETLには何を使っているのか気になる
• 先週neonに応募したが、買収のニュースが出て、今朝すぐ不採用通知を受け取った。これまでで一番うれしい不採用体験だ。今回で3回連続で買収される会社に入社しそうになったので、もう安定を求めたい。neonチームおめでとう。neonは好きで使っているが、この買収であまり変わらないでほしい
  • 買収前にKenna Securityに入社したが、1か月後にCiscoに買収された。本当にひどい経験で、Kennaのリーダーシップがいる会社やCiscoでは二度と働かない
  • むしろ逆の経験だ。買収の時期に入社するのは最も面白いタイミングだった。自分の場合、買収統合の経験のおかげでよくスカウトされた
  • エンジニアリングマネージャー1年目のときに買収プロセスの最中にいて、2度のレイオフを乗り切りながら残す人員の選定やチーム再編を手伝った。士気の低下はひどく、組織文化もまったく合わなかった。深刻なバーンアウトになって数か月休み、今は再びICとして幸せに働いている
  • 自分の予想では、neonチームはDatabricksのOnline Tables技術に組み込まれると思う。製品的にも筋が通っている
  • もしneonの昔の企業価値の時点で入社して、ちょうどベスティングが終わったところなら、突然まとまった金額を手にしたはずだが、どんな感じだったのか気になる
• Databricksは自分が使ったソフトウェアの中で最もイライラするゴミ。こんなものを自発的に使う人がいるのが不思議だ
  • Databricksは2013年、Sparkがいまひとつだった頃に始まり、Sparkをより良く、より速くした。製品は今もSpark中心だが、IcebergとDuckDBの組み合わせのほうが95%の企業に向いていると思う。より安く、より速く、扱いやすく、私たちもDefiniteでその前提のもとにデータプラットフォームを作っている（ETL、BI、Data Lakeをすべて含む）
  • Databricksはデータ界のJiraだ。誰も使いたくないし、イマイチなのに、すべてのユーザーに合わせようとした機能の寄せ集めで、どれもこれも中途半端だ。今ははるかに良い代替がたくさんあるので、自分の意思でDatabricksを選ぶことはない
  • 本当に同意しがたい。Hadoop出身者として、Databricksはユートピアだ。安定していて、速く、大規模データセットにも見事にスケールする。ただし価格が高すぎるのが最大の不満だ
  • 昔はDatabricksプラットフォームが好きだった。2020〜2021年にはAWS、Azure、Snowflakeに対して合理的な代替はほぼDatabricksしかなかった。今は機能の乱発、頻繁な変更、買収などで散漫になっており、機能名もひどい
  • IBM系ソフトウェア（みんなが使うからうちも使う）にまだ市場が残っていたということか
  • 正直、Databricksは本当に退屈な製品だ。2010年代後半を思い返すと、Spark-as-a-Serviceは卓越していて、企業が自前でSparkを安定運用するのに失敗していた時代だった。ハイパースケーラーの一次サービスも貧弱で、Databricksノートブック形式のJupyter互換性問題などもあったが、オンプレクラスターの不安定さのほうがより大きな悩みだったので、プレミアムを喜んで受け入れていた。当時のDatabricksはそれでも立派な10億ドル企業だった。しかしSpark-aaSだけでユニコーンにはなれなかった。AWS EMRが競合としてゆっくり追い上げてきており、結局Databricksも製品をむやみに膨らませる成長戦略に全振りし、データ、レイク、ハウスといったバズワードの洪水になった。2025年現在のDatabricksの下り坂は、エンシッティフィケーションの苦い一断面だ。いつかLarry Ellisonに買収され、市場から消えるのかもしれない。最近の新規プロジェクトでなぜDatabricksが選ばれるのか理解できないが、5年以上使ってきたエンタープライズは簡単には離れられないだろう。今後シェアは落ちるだろうが、しばらくは稼ぎ続ける。これが業界の循環で、最終的にはエントロピーが勝つ。そこまで嫌いにはならない。かなり良い歴史を作った会社だった
  • Serverlessを強調しすぎているが、限界と隠れた落とし穴が多すぎて本当に狂いそうになる
  • Sparkホスティングが本当に革新的だったのか疑問だし、Spark自体が既存企業のデータ処理の90%には複雑すぎるのではないかと常に思っている。この会社の価値がなぜこんなに高いのか理解できない
  • Cookieを無効にするとウェブサイトが完全に表示されない。これは致命的なレッドフラグだ。ウェブサイトひとつ作れない会社が良いデジタル製品を作れるとは思えない
• DatabricksはOracle級にひどい。Neonも台無しにするか、高額化するに違いない。中長期的にはNeonの代替を探すつもりだ
  • DatabricksのM&A戦略は、買収した会社を窒息させる構造だ。Iceberg、DuckDBなどオープンソースの大変動に苦戦している。買収によるイノベーションを試みているが、企業文化のせいで買収先が潰れていく。自分はビッグデータ業界出身（元Snowflake）なのでバイアスはあるかもしれないが、オープンソースがますます力をつけている流れは確実に見える。この変化がどうなるのかとても気になる
• 記事原文の引用: 「NeonがGAに移行した昨年は、作られたデータベースの30%がAIエージェントによるものだったが、最近見直したところこの比率は80%を超えていた。つまりAIが人間の4倍多くDBを作ったということだ。」これはいろいろな警報が鳴るデータだ。DatabricksはPostgresをAIソリューションとして売り込みたいように見える。最近の世の中は本当に不思議だ
  • そのうち実際にアクティブ利用されているDBが何個あるのか気になる
• Neonチームおめでとう。作ったものはとても気に入っている。ただ、Databricksとの関連やシナジーは正直感じられず、Neonが別製品として存続してほしい。そうでないと、市場から確かなPostgresプロバイダーをひとつ失うことになる
  • Azureへの依存が高いので、すぐには消えない気がする。Databricksは分析DBだけでなくトランザクションDB領域にも拡大しようとしている動きだ
  • FAQでは独立運営すると言っているが、実際の結末は見えていると思う
• NeonチームがHNに投稿した最初の投稿を覚えている。そのときもクールなアイデアだとコメントしたし、まだ自分で使う必要はなかったが、いつか使うだろうと思っていた。だが、こういう買収ニュースを見ると懐疑的になる。これからはユーザーより所有者の立場に重きが置かれそうで心配だ。原理的には両者の立場は一致するはずだが、実際にそうなることはまれだった
  • Neonの最初の投稿は自分も覚えている。ストレージとコンピュートの分離が新鮮で、Pageserverについて質問もした。その後2年もしないうちに、自分もTurso databaseで似たような分離ストレージに取り組むことになった。Neonチームに改めてお祝いを伝えたい
  • 買収のニュースに自分も立ち止まってしまった。AIユーザーを優先することが、開発者と利益の一致につながるとは信じがたい。PostgreSQLコアに関わる技術はオープンソースコミュニティの助けになることを願う
• Neonチームに祝意を伝える。素晴らしい製品だ。もちろんVC支援を受けていれば、こういう結末は避けがたいとも思う。NikitaたちがDatabricksに同化せず、強くあり続けてほしい
• これは本当に興味深い展開だ。OLTPとOLAPの収束のしかたとして正しい方向だと思う。OPと一緒にSingleStoreでHTAPシステムを作った経験がある。OLTPとOLAPを単一データベース（1回のコピーで両方を支える）にしようとしたが、HTAPはうまくいかなかった。OLTPはPostgres、OLAPはデータウェアハウス／レイクとして分け、その間のレプリケーションを効率的に設計すべきだ。同期レプリケーションは難易度が高い。カラムナストアはOLTPの書き込みをうまく受けられない。DatabricksとNeonが「最新のPostgresテーブルをUnity Catalogで直接活用する」シナリオを実現できるか期待している（Debezium、Kafka、Flink、Icebergを経由せず、SparkがIcebergの状態維持を担う）
  • OPとはNeon創業者のNikita Shamgunov（元MemSQL/SingleStore創業者）のことか、という質問
• Neonチームおめでとう。正直やや残念だ。CockroachDBがBusiness Sourceに移行して生まれた空白をNeonが埋めてくれると期待していた。Databricksに買収されたことで、Neonは魅力が薄れたように感じる。大企業が重要インフラを担ってくれるとは信じにくい。「モダンな」Postgresqlへの需要は十分にあるが、代替候補のどれも本流から離れていっている（価格、互換性、ソース公開の有無などの面で）。Postgres代替を探すときは次を比較した
  (1) AWS RDSはすでに使っていたが、高価で、スケーラビリティや運用上の問題があった
  (2) AWS Auroraは運用上の問題の一部を解決するが、別の欠点を伴い、他のwire互換Postgres代替と似た限界がある
  (3) CockroachDBは非常に面白かったが、ツールチェーン互換性や深い互換性の問題があり、当時はオープンソースだった
  (4) Neonはまだ未成熟に見えて採用しなかったが、興味深く、多くの問題を解決できそうだった
  (5) Yugabyteもやはり興味深い技術だったが、さまざまな互換性問題があった
  自前でPostgresをホスティングすることも考えたが、Kubernetesとpostgresの自前運用負担が大きく悩んだ。自前のレプリケーションや運用機能はまだ成熟不足で、アップグレード時の全データのアンロード／リロードも非常に面倒だった。スケールや自動化も簡単ではなかった
  • YugabyteのクエリエンジンがPostgresベースらしいので比較したのだろうが、Neon自体がPostgresであることを思い出させる
  • 「最高のモダンなPostgres代替は、（5年後の）Postgresそのもの」という自分の短い経験を共有
  • 他のwire互換Postgresql代替の「同じ欠点」とは何か、もっと聞きたい