Elasticsearchを倒すPostgres拡張 — ParadeDBの開発者ファースト戦略

World Startup Report

Postgresの中に検索エンジンを作る

データベースの世界には長年、一つの「常識」があった。リレーショナルデータベースと全文検索エンジンは別物であり、両方が必要なら両方を運用しなければならない、というものだ。PostgreSQLにデータを保存し、Elasticsearchで検索する。この二重構成は、何百万もの企業が当たり前のように受け入れてきたアーキテクチャだった。

ParadeDBは、この常識を真正面から否定する。PostgreSQLの拡張機能（Extension）として全文検索とアナリティクスを直接組み込む。データを別のシステムに複製する必要はない。同期の遅延もない。運用するインフラは一つだけ。開発者がもっとも慣れ親しんだPostgresの中で、すべてが完結する。

公開情報によると、2023年に設立されたこのスタートアップは、すでに40万以上のOSSデプロイを達成し、Craft Venturesを中心とした$12MのSeries Aを調達している。創業からわずか2年で、検索インフラの世界に本格的な地殻変動を起こしつつある。

Elasticsearchの「重さ」という課題

Elasticsearchは素晴らしいプロダクトだ。2010年の登場以来、全文検索のデファクトスタンダードとして君臨し、数え切れないほどの企業がその恩恵を受けてきた。しかし、その「重さ」は年々、開発者にとっての大きな負担になっていた。

Elasticsearch vs ParadeDB — アーキテクチャの違い

Elasticsearch

独立したクラスタ

JVMベース。専用クラスタの運用が必要。データ同期パイプラインの構築・保守が開発者の負担に

ParadeDB

Postgres拡張

Rustで実装。CREATE EXTENSIONで有効化。SQLでそのまま全文検索。追加インフラ不要

Elasticsearchを本番運用するには、JVMのチューニング、シャーディング戦略の設計、クラスタの監視、そしてPostgresとの間のデータ同期パイプラインの構築が必要になる。中小規模のチームにとって、検索機能のためだけにもう一つのインフラを運用するのは過剰な投資だった。

さらに厄介なのは「データの一貫性」の問題だ。Postgresに書き込んだデータがElasticsearchに反映されるまでにはタイムラグがある。このラグが引き起こすバグは、デバッグが困難で、ユーザー体験を静かに蝕む。ParadeDBのアプローチなら、データはPostgresに一元化されるため、一貫性の問題がそもそも発生しない。

1/10

インフラコスト削減

同期遅延

SQL

クエリ言語そのまま

Harvard CS出身CEOの原体験

ParadeDBの共同創業者でCEOのPhilippe Noëlは、Harvard大学でコンピュータサイエンスを学んだ。在学中からオープンソースコミュニティに深く関わり、データベースの内部構造に強い関心を持っていた。

卒業後、Noëlはいくつかのテック企業でバックエンドエンジニアとして働く中で、繰り返し同じ問題に直面した。「Postgresにデータがあるのに、検索のためだけにElasticsearchを立てなければならない」。このフラストレーションは、彼だけのものではなかった。Hacker Newsやredditのバックエンド開発者コミュニティでは、同じ不満が何度も繰り返し語られていた。

転機は、Rustの成熟だった。Rustの安全性とパフォーマンスは、PostgreSQLの拡張機能を書くのに理想的だった。C言語で拡張を書く時代の危険性 — メモリリーク、セグメンテーションフォルト、未定義動作 — をRustなら回避できる。Noëlは共同創業者とともに、Rustで書かれたPostgres拡張として全文検索エンジンを一から設計することを決意した。

1
2023年 — 創業・OSS公開GitHubでpg_searchを公開。Hacker Newsのトップに登場し、開発者コミュニティで話題に。
2
2023年後半 — シード調達初期のトラクションを背景にシードラウンドを完了。フルタイムチームを構築。
3
2024年 — pg_analytics発表全文検索に加え、カラムナーストレージによるアナリティクス機能を追加。Postgresの万能化を加速。
4
2024年 — $12M Series ACraft Ventures主導。40万+デプロイの実績を背景に、エンタープライズ向け展開を本格化。

Craft Venturesは、David Sacksが率いるシリコンバレーの有力VCだ。PayPal、Slack、Yammerなどの経験を持つSacksは、開発者ツールの市場価値を深く理解する投資家として知られる。ParadeDBへの投資は、「Postgresエコシステムの拡張」という大きなトレンドへの賭けでもある。

実際、Postgresは世界で最も人気のあるリレーショナルデータベースの一つであり、Stack Overflowの開発者調査でも常に上位に位置する。そのPostgresの機能を拡張するというアプローチは、既存のユーザーベースをそのまま潜在顧客に変えるという、極めて効率的なGo-to-Market戦略だ。

開発者がいる場所で戦う戦略

ParadeDBの戦略を一言で要約するなら、「開発者がいる場所で戦う」ということになる。新しいデータベースを売り込むのではなく、開発者がすでに使っているPostgresの中に価値を届ける。この「拡張戦略」は、単なる技術的な選択ではなく、深い市場洞察に基づくビジネス戦略だ。

ParadeDBの開発者ファースト戦略 — 3つの柱

01 ゼロ摩擦の導入

CREATE EXTENSIONの一行で有効化。新しいインフラの構築不要。学習コストもSQLの知識だけで済む。

02 OSSファーストの信頼構築

コアはAGPLライセンスで完全公開。開発者はソースコードを読んで安心できる。コミュニティからのフィードバックが製品を磨く。

03 既存エコシステムとの共存

pgvector、PostGIS、Citus等の他のPostgres拡張と共存可能。開発者の既存投資を無駄にしない。

この戦略の本質は、「新しいカテゴリを作る」のではなく、「既存のカテゴリに新しい能力を追加する」というアプローチだ。開発者にとって、新しいデータベースを採用するコストは計り知れない。スキーマの移行、アプリケーションコードの書き換え、運用ノウハウの蓄積 — すべてがゼロからのスタートになる。

ParadeDBのマネタイズモデルもこの戦略と整合的だ。OSSのコアは無料で提供し、エンタープライズ向けのクラウドホスティング、SLA付きサポート、高度なセキュリティ機能を有償で提供する。OSSで開発者の信頼を獲得し、エンタープライズで収益を上げる — HashiCorp、Confluent、Databricksが歩んできた道と同じだ。

日本のスタートアップが学べること

ParadeDBの物語は、日本のスタートアップに複数の重要な示唆を与えてくれる。

1
「新しいカテゴリ」を作る必要はない既存のエコシステムの中に不足している機能を追加する、という戦略は、市場教育のコストを大幅に削減する。日本のB2Bスタートアップも、Salesforceの拡張、Slackのアプリ、AWS上のマネージドサービスなど、既存プラットフォームの「隙間」を狙うアプローチが有効だ。
2
OSSは最強の営業チームParadeDBはOSSで40万デプロイを達成し、その実績をもとにSeries Aを調達した。コードそのものが営業してくれる。日本でもOSSファーストのスタートアップは増えつつあるが、まだ少数派だ。
3
「重い」ソリューションへの反発は常にチャンスElasticsearchがParadeDBの機会を生んだように、日本でも「使いこなすのが大変なエンタープライズツール」は数多くある。その複雑さを劇的に減らすプロダクトには、巨大な需要が存在する。

ParadeDBが証明しつつあるのは、巨人を倒すのに巨人になる必要はないという事実だ。Elasticsearchは時価総額数十億ドルの上場企業だ。しかし、ParadeDBは正面から競合するのではなく、開発者が日常的に使うPostgresの中から、静かにその領域を侵食していく。

「開発者がいる場所で戦う」 — このシンプルな原則は、技術の世界だけでなく、あらゆるビジネスに通じる本質を含んでいる。顧客のワークフローを変えるのではなく、顧客のワークフローの中に溶け込む。それが、小さなチームが巨人に勝つための最も確実な戦略なのかもしれない。

開発者がいる場所に、
価値を届ける。
それが最短の勝ち筋だ。

ParadeDBはElasticsearchと戦わない。開発者がすでにいるPostgresの中に、静かに検索エンジンを届ける。40万デプロイが証明するのは、最良の戦略とは顧客を動かすことではなく、顧客のもとへ行くことだ。

Elasticsearchを倒すPostgres拡張。ParadeDBの開発者ファースト戦略