Aurabase vs Convex: ネイティブ SQL それともリアクティブ バックエンド?

Aurabase は、PostgreSQL 16 標準 (SQL、クラシック移行、RLS ポリシー) に基づいています。 Convex は逆の道を歩みます。公式ドキュメントにはこの選択について明確に記載されています: 「セットアップするものは何もなく、SQL を記述する必要もありません。JavaScript を使用してアプリのニーズを表現するだけです。」 (docs.convex.dev/database、2026 年 8 月 24 日にアクセス)。凸テーブルには、最初に insertで作成された、オプションの TypeScript スキーマによって型指定されたドキュメントが格納されます。DDL を書き込む必要はありません。

スキーマで宣言されたインデックスを使用した、一般的な凸クエリは次のようになります。

// 凸型クエリ — SQL ではなく TypeScript
import { query } from './_generated/server'
import { v } from 'convex/values'

export const getOpenTasks = query({
  args: {},
  handler: async (ctx) => {
    return await ctx.db
      .query('tasks')
      .withIndex('by_completed', q => q.eq('completed', false))
      .collect()
  },
})

どちらのモデルも厳密には優れているわけではありません。 Convex のクエリ ビルダーは、構築によって SQL インジェクション バグのクラス全体を排除します。また、独自のクエリ言語に閉じ込められてしまいます。データ層を完全に書き換えなければ、標準の BI ツール、既存の Postgres ORM、pgvector や pg_graphql などの SQL 拡張機能はありません。

Convex では、デフォルトですべてのクエリが応答します。クライアントはデプロイメントへの WebSocket 接続を開き、エンジンは各リクエストによって読み取られたすべての行 (その「読み取りセット」) を保持します。突然変異がこの読み取りセットに影響を与えるとすぐに、関数はサーバー側で再実行されます。更新された結果は、サブスクリプション コードを記述することなく、クライアントにプッシュされます (stack.convex.dev/how-convex-works、2026 年 8 月 24 日にアクセス)。

Aurabase リアルタイムは、オプトインで逆の方法で機能します。 NATS JetStream は PostgreSQL 変更ストリーム (CDC) をブロードキャストします。 channel().on('postgres_changes', …)を介してチャネルを明示的にサブスクライブし、列によるフィルタリングが可能です。これはライブ ビュー用に記述するコードですが、Postgres 論理レプリケーションによってサポートされる標準プロトコルであり、特定のクエリ ビルダーと組み合わせた独自のメカニズムではありません。

ここで見つかるとは思わなかった共通点: どちらのエンジンも Rust で書かれています。 Convex オープンソース リポジトリ (get-convex/convex-backend) は主に Rust クレートで構成されています。 TypeScript は、V8 エンジンを介した開発者関数の実行環境にのみ使用されます (stack.convex.dev/how-convex-works、2026 年 8 月 24 日にアクセス)。 Supabase — Elixir/Go/TypeScript/Node スタック — に対して、Rust コアは依然として Aurabase の真の差別化要因です。 Convex に対しては、いいえ、両方とも、予測できないガベージ コレクションの一時停止のない信頼性の高いトランザクション エンジンを構築することに賭けました。

違いはライセンスにあります。 Convex エンジン コード (get-convex/convex-backend) は、公正なソース ライセンスである FSL-1.1-Apache-2.0に基づいてリリースされます。 Convex Cloud と競合する製品の作成を除くあらゆる使用を許可します。各バージョンは、利用可能になってから 2 年後に純粋な Apache 2.0 に切り替わります。この条項は、リポジトリ (github.com/get-convex/convex-backend、2026 年 8 月 24 日にアクセス) 内の LICENSE.md ファイルで直接確認されています。 Rust ワークスペースと Aurabase JavaScript SDK は、MIT ライセンスに基づいてオープンソースで公開されており、遅延や使用制限はありません。

AIに関しては凸も抜かりはありません。そのネイティブ ベクトル検索には、スキーマで宣言されたベクトル インデックスを使用して actionsからアクセスできます。 @convex-dev/agent および rag.search()フレームワークを使用して、理論上は Aurabase のネイティブ RAG に匹敵する RAG 機能を形成します (docs.convex.dev/search/vector-search、2026 年 8 月 24 日にアクセス)。

したがって、本当の違いは「RAG と RAG なし」ではありません。 Aurabase には、NL2SQL エンジンも統合されています。これは、自然言語での質問を SQL クエリに変換し、実行前に検証され、制限されます。 Convex は構造的に同等のものを提供できません。変換する SQL がなければ、生成するものは何もありません。これは、製品の遅延ではなく、上記で説明したアーキテクチャの選択の直接的な結果です。

Convex は、デフォルトの米国東部リージョン (docs.convex.dev/production/regions および news.convex.dev、2026 年 8 月 24 日にアクセス) に加えて、2026 年 2 月 6 日以降デプロイされた EU West (Ireland)リージョンを提供します。認識されるに値する真のオプションです。しかし、Convex Inc. は米国法に基づく会社であり続けます。創設者兼最高経営責任者（CEO）のジェイミー・ターナー氏は、サンフランシスコに拠点を置いていると述べた（news.convex.dev、Insight Partners主導のシリーズBで5,700万ドルを調達、2026年8月4日）。アイルランド地域を選択しても、データをホストしている会社の管轄区域は変更されません。

これは、Supabase で文書化されているものとまったく同じメカニズムです。親会社が米国に留まる限り、管理委員会で欧州地域をチェックしただけでは、クラウド法の法制度から抜け出すには不十分です。 Aurabase SAS は、フランスの法律に基づいて設立された会社で、ドイツ (ニュルンベルク、ファルケンシュタイン) とフィンランド (ヘルシンキ) で検証済みの生産インフラストラクチャを運営しています。

さらに詳しく: CLOUD 法によって BaaS の選択が変わる理由

コンベックスは、マーケティングベンチマークの競争に反対するという公の立場をとっている。彼の投稿のタイトルにはニュアンスはありません。「私はデータベースのベンチマークなど気にしません (そしてあなたも気にする必要はありません)」 (stack.convex.dev/on-competitive-benchmarks、2026 年 8 月 24 日にアクセス)。標的型攻撃ではなく、想定された姿勢の選択であるため、この投稿では特定の競合他社の名前は挙げられていません。

Aurabase の立場は同じ観察に基づいていますが、数値の公開を放棄するのではなく、再現可能で最新のベンチマーク手法を公開するという逆の方向をとっています。これはまだ進行中の作業です。完全な方法論が示されるまで、この記事ではパフォーマンスの数値は強調されません。

Convex は、スキーマからサーバー関数、React クライアントに至るまで単一の言語を使用し、手動で生成することなくエンドツーエンドの型付けを行うという根本的な選択を行いました。これは、すでに 100% TypeScript を使用しているチームにとって、生産性の大幅な向上です。

Aurabase JavaScript SDK は、 @aurabase/*というラベルの付いた 10 npm パッケージで配布されており、すべて公開され、インストール可能です。 Python、Dart、Rust SDK もリポジトリに存在します。これら 3 つはまだそれぞれのレジストリ (PyPI、pub.dev、crates.io) で公開されていません。現時点では、Git リポジトリに依存してインストールすることしかできません。紙の上では多言語をより広範囲にカバーしますが、完全に主張する前に実際の実行のギャップを埋める必要があります。

Aurabase は、PostgreSQL 16 標準と PostgREST 互換 API に基づいています。スキーマとデータのエクスポートは、従来の pg_dump/pg_restore を使用して、Aurabase またはその他の Postgres に実行されます。

Convex は SQL に依存しません。標準のリレーショナル形式へのエクスポートに直接相当するものはありません。 Convex アプリケーションを SQL バックエンドに移行するには、エクスポート ファイルを変換するだけでなく、スキーマをリレーショナル テーブルに改造し、データ アクセス レイヤーを書き直す必要があります。

チームがすでに 100% TypeScript を使用しており、レスポンシブな React アプリを構築しており、SQL や Postgres 拡張機能に大きく依存していない場合、Convex には製品上の大きな利点があります。具体的な利点は 2 つあります。構成不要の自動応答性と、フロントエンド/バックエンド統合のバグ全体を軽減するエンドツーエンドのタイピングです。

SQL、RLS Postgres、データポータビリティ、またはフランスの親会社によるドイツ/フィンランドのホスティング地域が意思決定基準となる場合、妥協が生じます。これが、Aurabase が差別化要因を構築する場所です。

オープンソースとセルフホスティングに焦点を当てた比較をしたいですか? Aurabase と Appwriteを参照してください。 Postgres ベンチマークの比較とアーキテクチャについては、「 Aurabase と Supabase」を参照してください。