$5.4B revenue run-rateのDatabricks、lakehouseをAI agent基盤へ広げた転換

Databricksは、Apache Sparkを生んだ研究者たちの成果を、企業が使い続けられるdata platformへ変えるところから始まった。

Ali Ghodsiは、現在のDatabricksを支えるdata and AI infrastructureを「enterprises will rely on for decades」と表現している。出典

研究プロジェクトから会社へ

2013年、UC BerkeleyのApache Sparkの研究・開発コミュニティを背景に創業した。

出発点は新しいBI画面ではなく、大量データを扱うengineerが、計算基盤と分析環境を同じ場所で使いたいという問題だった。出典

lakehouseという転機

warehouseとdata lakeが分かれると、データのコピー、schema管理、権限設計が増える。

DatabricksはDelta Lakeをopen source化し、lakeにACID transactionsと信頼性を持ち込む方向へ進んだ。

これは機能追加というより、data architectureの言葉を作る選択だった。出典

AIへの広がり

2023年にはDollyを公開し、6B parameterのmodelを1台で30分にfine-tuneする例を示した。出典

その後MosaicMLを取り込み、AI Search、MLflow、Agent Bricksへと、dataの上にAIをproduction化する道具を重ねた。出典

大きくなっても統合を続ける

2025年9月にはrevenue run-rate $4B、2026年2月には$5.4Bを公表し、AI productsも$1.4Bへ伸びた。出典

LakebaseやGenieを加えた現在のDatabricksは、分析基盤からAI agentsとapplicationの実行面へ広がっている。

この軌跡から見えるのは、研究成果をSaaSへ包装したことではない。

データの保存、変換、権限、評価、AI実行を一つの運用文脈へ寄せ続けたことが、次の市場を作る土台になったということだ。

Databricksは、data warehouseとdata lakeが分断され、AI projectがpilotからproductionへ進めないenterpriseの痛みに刺さる。

Lakehouse、governance、MLflow、AI toolingを同じplatformに置くことで、データ移動と運用境界を減らす。出典

特に既存データを捨てずにanalyticsとAIを進めたい組織に適合する。

顧客事例ではFortune 500の60%以上が利用すると説明されており、platform統合の需要を示す。出典

moatは、Spark・Delta Lake・MLflowを中心に蓄積されたdata engineeringの標準性と、Unity Catalogによるgovernanceの組み合わせにある。

単一featureではなく、既存運用に深く接続するplatformとしてのswitching costが形成される。出典

ネットワーク効果は中程度。

OSSとcommunityが技術者・integrations・知見を増やす一方、データそのものは顧客ごとに閉じるため、SNSのような直接的効果ではない。

Spark ecosystemとpartner networkが間接的な効果を生む。出典

主な対象は、複数cloudや大規模データを扱い、data engineering、BI、machine learning、AI applicationを分断せずに運用したいenterpriseのdata platform責任者。

小規模な単機能BIや完全なself-hostedを求めるチームには過剰になり得る。出典

第一に、Apache Spark・Delta Lake・MLflowというopen sourceの基盤をenterprise運用へ接続したこと。出典

第二に、AIを別製品として売らず、既存のdata governanceと同じ面に置いたこと。

2026年時点で$5.4Bのrevenue run-rateと>140%のnet retentionを公表している。出典

統合platformは範囲が広く、導入時の設計・権限・cloudコストが複雑になりやすい。

公式docsもdeployment、monitoring、disaster recoveryまで複数phaseで扱う必要を示す。出典

また、AI機能の品質・安全性・コストは継続的な評価が必要で、Databricks自身もproduction-quality AIの課題としてprivacy、quality、costを挙げている。出典

成長はdeveloper adoptionとenterprise expansionの二層構造だ。

OSS由来のSpark・Delta Lake・MLflowで技術者の入口を作り、cloud marketplace、partners、enterprise salesで組織導入へ広げる。

2026年発表では$1M超のannual revenue run-rateを持つ顧客が800社超とされ、land-and-expandの強さが見える。出典

主要チャネル: content, community, enterprise-sales, partners, developer-advocacy

カテゴリを作るには、既存のdata lakeとwarehouseの境界を単に批判するだけでなく、移行経路とgovernanceまで製品に含める必要がある。

Databricksのようにopen sourceの採用面を維持しながらenterpriseの運用課題を吸収すると、技術者の支持を売上へ接続しやすい。出典

日本で展開するなら、製造・金融・小売の現場データを、権限管理と監査要件を保ったままAI applicationへ接続する導入設計が鍵になる。

高いplatform費用を正当化するには、PoCではなく業務KPIと運用コストの改善を最初から測るべきだと考える。