Skip to content
Published on

エッジ & サーバーレスデータベース 2026 完全ガイド - Cloudflare D1 / Hyperdrive / Turso / PlanetScale / Neon / Supabase / Convex / Fauna / Xata 徹底解説

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

「2026年のデータベースはもはや一箇所にいない。ユーザーの隣に住むか、ゼロまで眠るか、その両方をする。」 — Cloudflare Developer Day キーノート、2025年4月

エッジコンピューティングとサーバーレスワークロードの爆発的な普及で、データベースは単一リージョンRDSだけでは不足する時代になりました。Cloudflare Workersは世界330都市でV8 isolateを5ms以内に起動できますが、データを取りに us-east-1 まで往復する250msがかかれば、エッジに関数を置く意味が消えてしまいます。この差を埋めるために、2020年代前半から「エッジデータベース」という新カテゴリが生まれ、2026年現在、その地形は買収・廃業・再編を経て完全に塗り替わりました。

本稿では、Cloudflare D1, Hyperdrive, Workers KV, Durable Objects, R2, Queuesを含むCloudflareスタックから、Turso (libSQL), PlanetScale (Vitess), Neon, Supabase, Convex, Fauna, Xata, Tigris, Upstash, Momento, Vercel Postgres, MongoDB Atlas Serverless, DynamoDB, Aurora Serverless v2, CockroachDB Serverless, Spanner, Cosmos DB for PostgreSQLまで、2026年5月時点で生き残った主要製品を一本に整理します。

1. 2026年エッジ・サーバーレスDB地図 — 5つの座標系

エッジ・サーバーレスDBは2軸で分類するのが最もすっきりします。データモデル(SQL / KV / Document / Reactive) と分散戦略(エッジレプリカ / 単一リージョン自動スケール / グローバルマルチリージョン) です。

カテゴリ代表製品分散戦略
エッジSQLiteCloudflare D1, Turso, LiteFS, Fly Postgresエッジレプリカ、msレベル読み込み
サーバーレスPostgresNeon, Supabase, Vercel Postgres, Aurora Serverless v2単一リージョン、ゼロスケール、ブランチ
サーバーレスMySQLPlanetScale, Aurora Serverless v2 (MySQL)Vitessシャーディング、ブランチ
グローバル分散SQLCockroachDB Serverless, Spanner, YugabyteDBマルチリージョン合意
Reactive / フルスタックConvex, Supabase Realtime, InstantDBリアルタイム購読、sync
KV / キャッシュWorkers KV, Upstash Redis, Momento, Vercel KV, DynamoDBグローバルキャッシュ、キーベース
DocumentMongoDB Atlas Serverless, Fauna (終了), DynamoDBスキーマレス
コネクションプーラー + キャッシュCloudflare Hyperdrive, AWS RDS Proxy, PgBouncerエッジでRDB加速

選択の最初の分岐点は常に「自分のワークロードが読み込み中心か、書き込み中心か、グローバルか、リージョン限定か」です。読み込み中心のグローバルアプリならTurso, D1, Hyperdriveが最適、書き込み中心の単一リージョンならNeon, Supabase, Auroraが最適、強い一貫性が必要なグローバルならSpanner, CockroachDB、リアルタイム購読が必要ならConvexです。

2. 「エッジデータベース」とは何か — 2つの定義

「エッジデータベース」は2020年以降に生まれた新しい用語で、定義が統一されていません。2026年時点で市場が定着させた2つの意味があります。

狭義 — エッジレプリカ(Edge Replica): ユーザーに近いエッジPoPに読み取り専用レプリカを置き、書き込みは単一のプライマリリージョンに送るモデルです。Tursoの組み込みレプリカ、Cloudflare D1のグローバル分散読み取りレプリカ(2024年公開)、PlanetScaleの読み取り専用リージョンなどが該当します。読み取りは5–20msまで下がりますが、書き込みは依然プライマリへの往復が必要です。

広義 — エッジランタイム互換(Edge-runtime-compatible): DBそのものは一箇所にあっても、エッジ関数(Workers, Vercel Edge, Deno Deploy)のV8 isolate環境で動くクライアントを提供するモデルです。Neon serverless driver, Supabase JSクライアント, PlanetScale serverless driver, Upstash REST APIが該当します。真の意味のエッジではありませんが、「WorkersからPostgresを呼び出す」という非常に一般的なシナリオを解く重要な道具です。

エッジランタイムの制約を理解しておく必要があります。Cloudflare WorkersとVercel Edge RuntimeはNode.jsではなくV8 isolateで動くため、long-lived TCPコネクションが維持できず、node:net, node:dnsも制限されます。そのため伝統的なpgドライバは使えず、HTTP/WebSocketベースのドライバ が必須です。NeonはPgBouncer + WebSocketプロキシを、PlanetScaleはHTTPベースのserverless driverを、Upstashは最初からREST APIで始めました。

3. Cloudflare D1 — Workers上のSQLite、2024年GA

D1はCloudflareが2022年5月に発表し、2024年4月にGAしたSQLiteベースのエッジデータベースです。Workersから呼び出すとsub-msバインディングで直接アクセスし、2025年からは世界マルチリージョン読み取りレプリカを自動展開します。

2026年5月時点のD1スペック

項目無料有料(Workers Paid)
DBサイズ5GB/DB10GB/DB
行読み込み5M/日25M/日(以後100万行あたり $0.001)
行書き込み100K/日50M/日(以後100万行あたり $1.00)
DB数1050,000
バックアップTime Travel 30日Time Travel 30日

D1はWorkersバインディングで直接呼び出すため、Hyperdriveのような別プーラーが不要で、SQLiteの全標準SQL(JOIN, CTE, ウィンドウ関数, FTS5)をサポートします。欠点はSQLiteの単一書き込みロック — 同時書き込みワークロードではキューイングが発生します。

// Workersから D1 を呼ぶ例
export default {
  async fetch(req: Request, env: { DB: D1Database }) {
    const { results } = await env.DB
      .prepare('SELECT id, name FROM users WHERE active = ?')
      .bind(1)
      .all<{ id: number; name: string }>()
    return Response.json(results)
  },
}

代表的な事例はCloudflare自身の1.1.1.1ドメイン登録サービス、OpenStatusのモニタリングデータ、Resendのドメイン/メールメタデータ保存です。韓国では Toss のサイドプロジェクト、NAVER WHALEの同期ベータでの使用報告があります。

4. Cloudflare Hyperdrive — Postgres/MySQL エッジ加速器

HyperdriveはWorkersから外部Postgres/MySQLを呼び出す際の2つの慢性病 — コネクションハンドシェイクコストとクエリ結果キャッシュ — を解決するため2024年4月にGAしました。2025年にMySQLサポートが追加されました。

動作原理は単純です。WorkersはHyperdriveバインディングを呼び出し、Hyperdriveがユーザーに最も近いPoPからプール済みコネクションでRDBへクエリを投げます。さらにGET性のクエリは結果をキャッシュし、次回呼び出しでms単位で返します。

価格(2026.05): Workers Paidプランに含まれ、別料金なし。キャッシュhit/missの統計ダッシュボードあり。

レイテンシ改善の例 — Cloudflare自社ベンチマークで us-east-1 Neon にワシントンから直接接続: 35ms p50、シドニーから直接接続: 280ms p50。Hyperdrive経由 — ワシントン: 6ms (キャッシュhit) / 38ms (miss)、シドニー: 12ms (hit) / 285ms (miss)。キャッシュhitが効くread系で大きな効果、missの時は直接接続並み。

// Hyperdrive 利用例 — Workers + Postgres
import { Client } from 'pg'

export default {
  async fetch(req: Request, env: { HYPERDRIVE: Hyperdrive }) {
    const client = new Client({ connectionString: env.HYPERDRIVE.connectionString })
    await client.connect()
    const { rows } = await client.query('SELECT * FROM products LIMIT 10')
    await client.end()
    return Response.json(rows)
  },
}

HyperdriveはD1の代替ではなくD1と併用するツールです。D1が合うワークロード(サービスメタデータ、ユーザープロファイル)はD1、大きなRDBが必要なワークロード(トランザクション、検索)はHyperdrive経由の外部Postgresという組み合わせが一般的です。

5. Workers KV, R2, Queues, Durable Objects — Cloudflareスタックの仲間

Cloudflareデータスタックは D1 以外にも4つの中核コンポーネントを持ちます。

Workers KV — グローバル分散KVストア。書き込みは約60秒で全PoPに伝搬するeventually consistentモデル。値サイズ25MB、キー512Bの上限。価格: 読み込み10M無料後 1Mあたり 0.50、書き込み1M無料後1Mあたり0.50、書き込み 1M無料後 1Mあたり 5.00。セッショントークン、フィーチャーフラグ、A/Bテストバリアントなど「一度書いてよく読む」データに最適。

Cloudflare R2 — S3互換オブジェクトストレージ。egressトラフィック無料が最大の差別化。価格: ストレージ 0.015/GB−月、ClassA(書き込み)0.015/GB-月、Class A(書き込み) 4.50/1M リクエスト、Class B(読み込み) $0.36/1M リクエスト。AWS S3比でegress 0円のため、メディア・ログ・バックアップ・静的アセットのホスティングコストを80%以上削減した事例も多いです。

Cloudflare Queues — メッセージキュー。60秒以内に全メッセージ配達保証、最大7日保管。価格: 1M操作で $0.40。EventBridge/SQSのエッジフレンドリーな代替。

Durable Objects (DO) — 単一インスタンスに強い一貫性を提供するstatefulプリミティブ。2025年にSQLiteベースのstorage backendへ移行し、事実上「ユーザーごとのSQLite DB」が可能になりました。チャットルーム、ライブ協業ドキュメント、ゲームルーム、リアルタイムカウンタなどのパターンに最適。価格: 5/Mリクエスト+5/Mリクエスト + 12.50/GB-月。Cloudflare自社の会議製品Realtime、Linearのライブカーソル、Notionのライブブロックでも利用が報告されています。

これら5サービス(D1, KV, R2, Queues, DO)はすべてWorkersバインディングで呼び出され、追加の認証/DNS往復なしにsub-msでアクセスできます。これがCloudflareスタックの最大の強みです。

6. Turso — libSQLと組み込みレプリカの発明

Tursoは2022年にGlauber Costa氏らが設立した会社で、SQLiteをforkして作ったlibSQLを中核としています。2024年の最も注目すべきイノベーションは組み込みレプリカ(Embedded Replica) — アプリプロセス内にSQLiteファイルを持ち、バックグラウンドでプライマリと同期するモデルです。

組み込みレプリカの効果: 通常クエリはメモリ/ローカルSQLiteからsub-ms応答、データは5–60秒間隔でプライマリからpull。Vercel Edge, Bun, Nodeのどこでも動作。読み込みはローカルディスクレベルのレイテンシ(0.1ms)、書き込みはプライマリ往復。

2026年5月のTursoスペック

プラン価格DB数行読み込み行書き込みストレージ
Hobby (Free)$05001B/月25M/月9GB
Starter$29/月6,0007B/月250M/月30GB + $0.30/GB
Scaler$299/月100,000100B/月5B/月1TB

Tursoは2025年にMooncake Labsを買収しlibSQL Server分散ビルドに注力、2026年にはマルチマスター同期エンジンのベータを発表しました。Convex, Linear, Cal.com などがユーザーごとのDB分離(per-user database)パターンでTursoを採用しています。

// Turso 組み込みレプリカの利用
import { createClient } from '@libsql/client'

const db = createClient({
  url: 'file:local.db',                 // ローカルSQLiteファイル
  syncUrl: 'libsql://my-db.turso.io',   // primary URL
  authToken: process.env.TURSO_AUTH_TOKEN!,
  syncInterval: 60,                      // 60秒毎にsync
})

// 読み込み — sub-ms (ローカル)
const users = await db.execute('SELECT * FROM users LIMIT 10')

// 書き込み — 即時ローカル反映 + バックグラウンドでプライマリ送信
await db.execute({ sql: 'INSERT INTO logs (msg) VALUES (?)', args: ['hi'] })

7. LiteFS (Fly.io) — SQLiteを分散させるもう一つの方法

LiteFSはFly.ioが2022年に発表したFUSEベースのSQLiteレプリケーションソリューションです。SQLite WALを捕捉し全トランザクションを別ノードへstreamingする方式で、「書き込みはプライマリ、読み込みはどのノードからでも」をサポートします。

2024年にFlyがLiteFS Cloudを終了し、ホスティング選択肢は消えましたが、LiteFS自体はオープンソースとして引き続き維持 されており、Fly Apps + LiteFSで自前運用する事例は残っています。WALベースのためトランザクション一貫性がTursoの同期モデルより強い点が差別化です。

代表的な採用は Fly.io 自身のインフラ、Aha! の一部モジュール、Crisp(カスタマーサポート)の一部ワークロードなどです。2026年に新規採用はほぼ止まり、TursoとD1がシェアをほぼすべて取りました。

8. PlanetScale — Vitessと無停止スキーマ変更

PlanetScaleはYouTube由来のVitess(MySQLシャーディングフレームワーク)をSaaS化した会社で、2024年までモダンスタックの事実上の標準でした。最大の差別化はブランチ(GitのようにDBを分岐) とdeploy request(スキーマ変更をPRのようにレビュー) の2つです。

2024年4月、PlanetScaleはHobby無料ティアを終了 し、これは日本・韓国の開発者コミュニティに大きな衝撃を与えました。2025年11月、PlanetScaleはVitess保守に集中する路線を再定義し、2026年現在ビジネスの70%以上がEnterprise Vitessホスティングから来ています。

2026.05 PlanetScaleプラン

プラン価格使用量ストレージ
Scaler$39/月1B行/月10GB
Scaler Pro$59/月100B行/月100GB
Enterprise個別無制限個別

PlanetScaleは真の「エッジDB」というより、単一リージョンMySQLを非常に上手く運用するSaaSです。Read-onlyリージョン(US/EU/AP)オプションでグローバル読み込みレイテンシを下げられ、HTTP serverless driver(@planetscale/database)でWorkersやVercel Edgeからも呼べます。

代表的な事例はVercel(自社データ)、Cash App, Square, Notion(一部ワークロード)、GitHub Copilotの一部メタデータです。韓国では Toss の一部分析ワークロードと当根マーケットの検索メタデータでの使用報告があります。

9. Neon — サーバーレスPostgresとブランチ、Databricks買収

Neonは2021年にHeikki Linnakangas(Postgresコアコミッター)が設立したサーバーレスPostgres会社で、ストレージとコンピュートを分離 した斬新なアーキテクチャが核です。コンピュートはゼロまでスリープ可能で5秒で起き上がり、ストレージはS3ベースのページサーバーで無限に拡張します。

最強の機能はDBブランチ — Gitブランチのように DBをCoW(copy-on-write)で複製し、PRごとに独立DBを持つパターン。CI/CDパイプラインでPRごとに1秒で新ブランチを作成し、マージで削除する方式が標準になりました。

2025年5月、Databricksが約10億ドルでNeonを買収 し、2026年現在Databricks LakebaseのOLTPバックエンドとして統合されました。買収後もNeon単体サービスは維持され、無料ティアも残っています。

2026.05 Neonプラン

プラン価格Compute Hoursストレージ
Free$0191.9 時間/月0.5GB
Launch$19/月300 時間/月10GB
Scale$69/月750 時間/月50GB
Business$700/月1,000 時間/月500GB

Neon は Vercel Postgres のバックエンドでもあります — Vercel は2023年から Neon とパートナーシップを結び、Vercel Postgres という名前でwrapping販売してきました。2025年のDatabricks買収後もこのパートナーシップは継続しています。

10. Supabase — Postgres + Auth + Storage + Realtime + Edge Functions

Supabaseは2020年にPaul Copplestoneが設立した「オープンソース Firebase」を標榜するBaaSです。Postgres + GoTrue(Auth) + Storage(S3 wrapper) + Realtime(Postgres logical replication) + Edge Functions(Deno) + Vector(pgvector)を1プラットフォームに束ねました。

2026年の最大変化はSupabase Branching GA(2024年10月)とSupabase Edge Runtime 2.0(2025年9月)の2つです。BranchingはNeonスタイルのDB分岐、Edge Runtime 2.0はDeno 1.46からDeno 2.xへアップグレードされ、cold startが50ms未満に下がりました。

2026.05 Supabaseプラン

プラン価格DBAPI
Free$0500MB50K MAU
Pro$25/月8GB100K MAU
Team$599/月100GB+無制限
Enterprise個別個別個別

Supabaseの強みは「1プロダクトに必要なものが1 SDKに揃っている」点です。Auth, RLS(Row Level Security)ポリシー、ファイルアップロード、リアルタイム購読を同じトークンで処理でき、フルスタック開発の速度が出ます。弱みはPostgreSQLとの結合が強すぎて、非Postgresバックエンドへの移行が難しい点。

代表的な事例はMozilla AI, Resend, Trigger.dev, Cal.com, Pieter Levelsの複数のインディプロダクトです。日本では SmartHR の一部内部ツール、freee の試験的プロジェクトで利用報告があります。

11. Convex — Reactive フルスタックサーバーレスDB

Convexは2022年にJamie Turner(元Dropbox エンジニアリングディレクター)が設立した「フルスタックreactive DB」です。独自トランザクションDB + 独自クエリエンジン + 独自JavaScript runtimeを束ねた単一プラットフォームで、クライアントがクエリを購読するとデータ変化のたびに自動的にpushされるモデルです。

技術的に最も興味深いのは決定論性(determinism) — 全てのquery/mutation関数はJavaScriptですが、syscallが禁止されたV8 isolate上で実行され、同じ入力 → 同じ出力が保証され、トランザクション衝突時の自動再試行が可能です。

// Convex query/mutation の例
import { query, mutation } from './_generated/server'
import { v } from 'convex/values'

export const listPosts = query({
  args: { authorId: v.id('users') },
  handler: async (ctx, { authorId }) => {
    return await ctx.db
      .query('posts')
      .withIndex('by_author', (q) => q.eq('authorId', authorId))
      .collect()
  },
})

export const createPost = mutation({
  args: { title: v.string(), body: v.string() },
  handler: async (ctx, args) => {
    return await ctx.db.insert('posts', args)
  },
})

2026.05 Convex プラン

プラン価格関数呼び出しストレージ
Starter$01M/月0.5GB
Pro$25/月25M/月50GB
Team$500/月250M/月500GB

Convexの弱点はlock-inが強いこと — 独自のクエリ言語と独自スキーマシステムを使うため、他DBへの移行が困難。代わりにフルスタックインディ開発や高速プロトタイピングでは無敵。代表的な事例はa16z投資ポートフォリオ多数、Cursorの一部機能、MoonshotAI(2025年に一部ワークロード移行)。

12. Fauna — 2025年5月にサービス終了

Faunaは2012年にEvan WeaverとMatt Freels(元Twitterエンジニア)が設立した分散NoSQL DBで、Calvin合意アルゴリズムとFQL(独自クエリ言語)、マルチリージョン強い一貫性を売りにしました。2010年代後半で最も野心的な分散DBプロジェクトの一つでした。

しかし2025年3月、Faunaは2025年5月30日のサービス終了を告知。理由は公式に「持続可能なビジネスモデル構築の失敗」。顧客には90日のデータ移行期間が与えられ、Convex, MongoDB Atlas, Couchbase Capellaが推奨代替として案内されました。

Faunaの終了は2020年代前半の「野心的分散NoSQL」カテゴリの限界を示す象徴的な出来事になりました。独自クエリ言語(FQL)の学習曲線、GraphQLインターフェースの完成度の不足、AWS DynamoDBとSpannerの間でのポジショニング失敗が累積した結果です。

移行経路別の推奨は一般的に — 強い一貫性と分散SQLが必要なら CockroachDB か Spanner、フルスタックreactiveが必要なら Convex、キーバリュー/documentなら DynamoDB か MongoDB Atlasです。

13. Xata — 2025年12月に新規登録終了

Xataは2022年にMonica Sarbu(Elastic出身)が設立した「Postgres + 検索 + 分析」ハイブリッドBaaSです。PostgresとElasticSearchを1スキーマで束ねた斬新なモデルで、Vercel・SaaSスタートアップ層で一時的に人気を博しました。

2024年、XataはPostgreSQLを100%標準にするためOrioleDBベースでバックエンドを再構築し、2025年12月に突然新規登録終了を告知しました。既存顧客は2026年末まで運用保証され、会社はOrioleDBやpg-roll(zero-downtime migration ツール)などのオープンソースプロジェクトへピボット。

OrioleDBはPostgresのstorage engineをcloud-native(分離ストレージ)に再構築したプロジェクトで、2025年にSupabaseがOrioleDBを買収し中核エンジニアを採用しました。つまりXataの技術資産はSupabaseに吸収され、2026年のSupabase PostgresはOrioleDBベースのオプションをベータで提供しています。

14. Tigris Data — グローバル分散オブジェクト + DB

Tigris Dataは2022年にOvais Tariq, Yevgeniy Firsov(元Uber分散システム)らが設立した会社で、2024年からS3互換のグローバルオブジェクトストレージへポジショニングを再定義しました。最初はdocument DBとして開始しましたが、AIワークロードのオブジェクトストレージ需要を見てピボットした事例です。

2026年のTigrisの中核価値は自動グローバル複製 — オブジェクトをどこから書いても自動的にユーザーに近いリージョンへ複製、egress無料、S3互換API。AIモデルチェックポイント、学習データセット、推論結果キャッシュなどのワークロードに最適。価格: ストレージ 0.02/GB−月、ClassAリクエスト0.02/GB-月、Class Aリクエスト 0.005/1K、egress $0/GB。

Cloudflare R2 と比べると — R2は単一リージョンストレージ + グローバルキャッシュ、Tigrisは真のグローバル複製。R2はegress無料から始めたとすると、Tigrisはグローバル複製まで無料。代表的な事例は Lambda Labs(AI GPUクラウド)、Modal Labs の一部ワークロード、Y Combinator AI スタートアップ複数。

15. Upstash — Redis / Kafka / QStash / Vector サーバーレス

Upstashは2020年にMehmet Dogan(元AWS)が設立した会社で、「ゼロまで眠りリクエスト課金されるサーバーレスRedis」というアイデンティティで始まりました。2026年現在のラインナップは以下です。

Upstash Redis — Redis 7.x互換、HTTP + WebSocket API、グローバル複製可能。価格: リクエストあたり $0.20/100K。Workers / Vercel Edgeで最初に入るキャッシュ・セッション・rate limit ツール。

Upstash Vector — 2024年発表のベクトルDB。pgvector・Pinecone代替。価格: リクエストあたり 0.40/100K、ストレージ0.40/100K、ストレージ 0.25/GB-月。

Upstash QStash — HTTPベースのメッセージキュー / スケジューラ。Cron + 再試行 + 指数バックオフ + 署名検証を1 SaaSで。価格: $1/100Kメッセージ。

Upstash Kafka — 2024年後半に運用終了。UpstashはKafkaラインを整理し、Redis・Vector・QStashの3本に集中。

Upstashの大きな利点は0 fixed cost — リクエストがなければ1円も払いません。サイドプロジェクト、indiehackers、トラフィック変動の大きいSaaSのキャッシュ・rate limit層として事実上の標準になりました。代表的な事例はVercel KVのバックエンド(2024年に終了、現在は自社 + Redis Cloudへ移行)、Trigger.dev, Resend, Linear の一部ワークロード。

16. Vercel Postgres, KV, Blob, Edge Config — パートナーシップの束ね

Vercel は2023年に Vercel Storage という傘の下に4製品を発表 — 全て外部パートナーのwrappingです。

製品バックエンド備考
Vercel PostgresNeon2025年GA、ブランチサポート
Vercel KVUpstash Redis (~2024) → Redis Cloud2024年後半にUpstashから移行
Vercel Blob自社(AWS S3上)グローバルCDN + 無制限
Vercel Edge Config自社(自社KV)ビルド時 + ランタイムのフィーチャーフラグ

2026年のVercelはデータ事業を整理する方向を明確にしました。自前のデータインフラを構築せず、Neon・Upstash・MongoDB などのパートナーのwrapperとして位置し、開発者体験に集中。請求はVercel 1か所にまとまり、ダッシュボードも統合されますが、バックエンドそのものはパートナーのインフラです。

これはデータカテゴリにおけるVercel の明確な自己評価です — 「我々はDB を作る会社ではなく、フロントエンド/エッジ関数を運用する会社」 — そしてデータは外部と束ねてパッケージで販売。CloudflareがD1・R2・KVを自前で作ったのと真逆の戦略です。

17. MongoDB Atlas Serverless — Documentのサーバーレス

MongoDB Atlas Serverlessは2021年に発表され、2022年にGAしたサーバーレスMongoDBオプションです。ゼロまで眠ることはしませんが、リクエスト/ストレージあたり課金され、capacityは自動拡張されます。

2026年のMongoDB Atlasの中核変化はAtlas Vector Search GA(2024年)とAtlas Search Nodes(2025年)の2つです。Vector Searchはhybrid search(キーワード + ベクトル)をサポートし、RAGバックエンドとして採用が増加。Search Nodesは検索ワークロードをmain clusterから分離します。

価格: Read Processing Units (RPU) 0.10/M、WriteProcessingUnits(WPU)0.10/M、Write Processing Units (WPU) 1.25/M、ストレージ $0.25/GB-月。M0 無料ティアはsandbox用に維持。

MongoDB Atlas Serverlessの強みはdocumentモデル + 強い一貫性 + トランザクション。弱みはV8 isolate環境からの直接呼び出しが難しい点 — Atlas Data API (HTTP) または Atlas App Services (公式wrapper) 経由が必要。代表的な事例は Adobe, eBay, Lyft, Forbes, Toyota Connected など大企業多数。

18. AWS DynamoDB & DynamoDB Streams — クラウドKVの絶対王者

DynamoDB は2012年にリリースされ、14年目を迎えるAWSの揺るぎないKV/document DBです。2026年時点の最大の変化はDynamoDB Standard-IA(infrequent access、ストレージコスト60%減)、PartiQLの安定化、2024年のGlobal Tablesマルチactive-active GAです。

価格モデルは2つ — On-demand(リクエストあたり 1.25/Mwrites,1.25/M writes, 0.25/M reads、ストレージ $0.25/GB-月)またはProvisioned(WCU/RCU予約、より安いがcapacity管理が必要)。2024年11月、On-demand価格が平均50%引き下げられ、再び魅力的なオプションになりました。

DynamoDB は真のエッジDBではありませんが、単一リージョンで sub-10ms p99 で応答し、Global Tables でマルチリージョン active-active もサポートします。日本のMercariは取引メタデータと通知キューで DynamoDB + Aurora の組み合わせを使い、LINE Yahooは一部の広告・メッセージ集計でDynamoDB Streams を活用。韓国のCoupangは中核の注文/配送メタデータにDynamoDB を広範に使用しています(Coupang Engineering Blogに記事多数)。

// DynamoDB を Workers / Edge から呼ぶ
import { DynamoDBClient, GetItemCommand } from '@aws-sdk/client-dynamodb'

const client = new DynamoDBClient({
  region: 'ap-northeast-1',
  credentials: { accessKeyId: env.AWS_KEY, secretAccessKey: env.AWS_SECRET },
})

const res = await client.send(new GetItemCommand({
  TableName: 'users',
  Key: { id: { S: 'u-1' } },
}))

19. Aurora Serverless v2 — Postgres・MySQLの自動拡張

Aurora Serverless v2 は2022年にGAしたRDS Auroraの自動拡張オプションです。v1と違いゼロまで眠ることはできない(最小0.5 ACU)ですが、0.5秒単位でACUを調整しトラフィック変動に即応します。2024年8月からAurora Serverless v2 がゼロスケールするオプション が追加され、真のサーバーレスになりました。

価格: ACU(Aurora Capacity Unit、約2GB RAM)あたり $0.12/時間。ゼロスケール時のcold startは約15秒。

Auroraは真のエッジDBではありませんが、RDSの全標準SQLとトランザクションをそのまま使いながらcapacity管理から解放される利点があります。日本のLINE Yahoo, CyberAgent, DeNA も Aurora を広範に運用しています。

代表的な事例は Slack, Robinhood, Samsung Electronics, Roblox など大規模SaaSの運用DBとして広く採用され、2026年も単一リージョントランザクションワークロードの事実上の標準です。

20. CockroachDB Serverless — 分散SQLのサーバーレス

CockroachDB は2015年にSpencer Kimball(元Google, Spanner影響)が作った分散SQL DBで、Postgres wire protocol 互換にマルチリージョン強い一貫性を提供します。CockroachDB Serverless は2021年に発表され2022年にGAしました。

2026.05 CockroachDB Serverless 価格

項目価格
無料ティア50M RU + 10GB ストレージ + 1リージョン
RU (Request Unit)$1.00/10M
ストレージ$1.00/GB-月
マルチリージョン追加RU課金

CockroachDB の強みは真のマルチリージョン active-active — どのリージョンで書き込んでも他リージョンに強い一貫性で複製され、1リージョン障害時は自動failover。弱みはコスト — 同一ワークロード基準で単一リージョンAurora対比2–3倍高くなるケースが普通です。

2024年、CockroachDB は無料ティアを整理し価格を引き上げ、日本・韓国のインディ開発者の間で賛否分かれました。代わりにグローバルfintech、多国籍SaaS、ゲームバックエンドなどのワークロードではほぼ代替不可。代表的な事例は DoorDash, Netflix(一部), Bose, Form3(英国fintech), Shipt。日本のCyberAgent はAbemaTVバックエンドの一部でCockroachDB を採用しています。

21. Spanner — Google のグローバルSQLとPostgreSQL インターフェース

Spanner は2017年にGCPで公開されたGoogleのグローバル分散SQL DBで、TrueTime API(原子時計ベースの時間同期)とPaxos合意でマルチリージョン強い一貫性を提供します。14年間Google内部で検証されたシステムで、コアの広告/決済システムがこの上で動きます。

2026年のSpannerの最大変化はPostgreSQL Interface GA(2023)とSpanner Graph(2025年リリース)の2つ。PostgreSQL Interface により Spanner を最初からANSI SQL + Postgres方言で使えるようになり、Spanner Graph は1システムでSQL + graphクエリの両方をサポートします。

価格: ノードあたり $0.90/時間(USリージョン、2024年GAの処理単位ベースのオプションはより細分化)。マルチリージョンはノードあたり約3倍。

Spannerの強みは検証されたグローバル強い一貫性と無限拡張。弱みはコストとGCP lock-in。日本のLINE Yahooは広告インベントリでSpannerを運用し、メルカリも一部の国際展開ワークロードで評価中という報告があります。

22. YugabyteDB · Cosmos for PostgreSQL · OrioleDB — Postgres互換分散DB

CockroachDB 以外にもPostgres互換分散DBは複数競合します。

YugabyteDB — 2016年にKarthik Ranganathan(元Facebook Apache Cassandra)が作った分散DB。PostgreSQL 11互換にマルチリージョン強い一貫性。2024年に Yugabyte Cloud 無料 sandbox 終了、現在は14日無料trial のみ。強みはCassandra出身の分散storage layer の検証、弱みは Postgres互換性が CockroachDB より少し弱い点。

Azure Cosmos DB for PostgreSQL — 2022年に Microsoft が買収した Citus を Cosmos DB の傘の下に統合した製品。分散Postgresシャーディングとhyperscaleを強調。価格: $0.27/vCPU/時間から。Microsoft スタックユーザーには自然な選択。

OrioleDB — Postgresの storage engine を cloud-native(分離ストレージ)に再構築したオープンソース拡張。2025年に Supabase が買収し中核エンジニアを採用。2026年現在 Supabase Postgres オプションでベータ提供。heapの限界(WAL負荷, vacuumコスト, freezing)を回避し、同じワークロードで5–10倍のthroughputを報告しています。

OrioleDB は真の分散DBではなくPostgres storage layer 改善 という点が差別化。マルチリージョン合意は依然として別レイヤー(Patroni, Hyperdriveのようなキャッシュ)が必要。

23. Momento — Redis の真のサーバーレス代替

Momentoは2022年にKhawaja Shams(元AWS DynamoDBリーダー)が設立した会社で、「Redisよりさらにサーバーレスなキャッシュ」を標榜します。Upstashと比較すると — UpstashはRedis互換、Momentoは独自API + Redis API互換オプション。

Momentoの差別化は0 fixed cost + 0 capacity planning。データが入れば自動的にcapacity拡張、トラフィックがなければゼロ。価格: データ転送 $0.50/GB(読み込み・書き込み合算)、ストレージ無料。

2024年、MomentoはMomento Topics(Pub/Sub)とMomento Cache(メインキャッシュ)の2ラインをGAし、2025年にはStorage(永続K/V)ベータを追加。代表的な事例は The Wall Street Journal, Walgreens, Pulpify, AWS のpartner workshop一部。

MomentoとUpstashの選択は — Redis API互換と独自クライアントがすでにあるならUpstash、真の0 capacity管理と価格の単純さが必要ならMomentoです。

24. Drizzle ORM 0.40 · Prisma 6 — ORMレイヤーの競争

エッジ・サーバーレスDBの台頭はORMにも大きな影響を与えました。伝統的なPrisma(2020年代前半の標準)はRustベースのquery engineを別プロセスで起動する構造で、V8 isolateで直接動かず、Cloudflare Workers での使用が困難でした。

2022年に登場したDrizzle ORMは Pure TypeScript でquery builder を作り、全ドライバ(libsql, postgres-js, mysql2, planetscale, neon serverless)をサポートしながら急速に標準化。2026年5月現在のDrizzle 0.40系は以下をサポートします。

  • TypeScript-first schema定義(SQL DDL自動生成)
  • D1, Turso, Neon, PlanetScale, Postgres, MySQL, SQLite, AWS Data API, Bun:sqlite
  • Drizzle Kit(スキーママイグレーションツール)、Drizzle Studio(GUI)
  • 2025年12月の Vercel 買収後もオープンソースで維持

Prisma 6(2024年9月リリース)はRust → TypeScript マイグレーション を断行しV8 isolateでも動作開始。2026年、Prismaは一部ドライバ(D1, Cloudflare Workers)ではまだDrizzleほど滑らかではないものの、schema-first開発体験と豊富なecosystem(Prisma Migrate, Prisma Studio, Prisma Pulse)が強み。

選択は — Workers・エッジ第一なら Drizzle、Next.js 標準 + 豊富なツールが必要なら Prisma。日本・韓国の開発コミュニティ共に2024年以降 Drizzle のシェアが急速に増加しました。

25. エッジDBが合うワークロード / 合わないワークロード

エッジ・サーバーレスDBは万能解決策ではありません。選択の核心基準は以下です。

合うワークロード

  • 読み込み中心のグローバルアプリ: ブログ、ドキュメントサイト、マーケティングページ、ソーシャルフィードキャッシュ — Turso, D1, Hyperdrive
  • 単一リージョンOLTP: SaaSダッシュボード、決済トランザクション、ユーザープロファイル — Neon, Supabase, Aurora Serverless
  • フルスタックreactive: チャット、ライブ協業、ゲームルーム — Convex, Supabase Realtime, Durable Objects
  • グローバルキャッシュ / rate limit: Workers KV, Upstash Redis, Momento
  • オブジェクトストレージ + CDN: R2, Tigris, Blob
  • AI 埋め込み / ベクトル: Upstash Vector, MongoDB Atlas Vector, pgvector on Neon/Supabase

合わないワークロード

  • 高書き込みOLTP: 取引所、広告クリックログ、IoTテレメトリ — むしろ Aurora・Bigtable・ClickHouse
  • 複雑トランザクション + 外部キー制約 + 多段JOIN: 分散SQLはすべて単一リージョンRDBより遅い — RDS・Auroraが正解
  • PB単位の分析: BigQuery, Snowflake, ClickHouse, Databricks
  • 強い一貫性 + グローバル: 高くてもSpanner・CockroachDBが事実上唯一

エンジニアリング判断の核は「自分のワークロードの read/write 比率、グローバル可否、一貫性要求」です。90%以上のSaaSは単一リージョンPostgres + グローバルキャッシュ(KV)の組み合わせで十分で、グローバル強い一貫性が本当に必要なワークロードは数えるほどです。

26. 価格比較 — 同じワークロード、異なる請求書

仮想ワークロード — 月10M API リクエスト、平均read 5回 + write 1回 per リクエスト、ストレージ50GB、グローバルユーザー。

製品月推定コスト備考
D1 + Workers (Paid)$25–605+1 呼び出し × 10M = 60M 呼び出し、すべてWorkers Paid内
Turso Starter$29 + α50M+10M = 60M 行、Starter上限内
Neon Launch + Workers19+19 + 5 (Workers) = $24単一リージョン Postgres、キャッシュなし
Supabase Pro$25100K MAU上限内
PlanetScale Scaler$3960M 行上限内
Aurora Serverless v2 (0.5 ACU平均)~$450.5 ACU × 720h × $0.12
CockroachDB Serverless$60–12060M × 2 RU/リクエスト = 120M RU
DynamoDB On-demand$4060M read + 10M write

同じワークロードでも請求書は2–5倍違い、トラフィック変動が大きいならゼロスケール(Neon・Aurora v2) が有利、トラフィックが一定なら定額(Supabase Pro・Turso Starter) が有利。全価格は2026年5月時点、無料ティア余裕と別単価が適用される場合があり、実際の請求書は異なる可能性があります。

27. 韓国の導入事例 — Coupang · Toss · 当根 · NAVER · NHN Cloud

韓国主要企業の2026年時点のデータベース選択は以下です。

Coupang — DynamoDB を中核の注文/配送メタデータに広範に使用。AWS環境 + JVMスタックの一貫性が決定要因。Aurora MySQL はほぼすべての商取引マスターデータに使用。ElastiCache Redis はセッション・リアルタイムカウンタ。

Toss(トス) — 中核決済は自社運用 Postgres + MySQL クラスタ。一部分析・実験ワークロードに PlanetScale, BigQuery。Toss証券・ペイメンツなど子会社が個別 stack 運用。サイド・実験ツールには Supabase・Neon 使用報告。

当根マーケット — Postgres + Redis コア。検索メタデータに PlanetScale、グローバルキャッシュに Cloudflare KV 一部検討。AI・ベクトルワークロードに pgvector + Pinecone。

NAVER · NAVER Cloud — Cubrid(自社DB) + MySQL + Postgres。Cloud DB事業として PostgreSQL, MySQL, MongoDB, Redis ホスティング提供。検索・広告は自社分散システム。

NHN Cloud — RDS 互換(Postgres・MySQL) + 自社分散システム(Pinpoint, Dooray)。ゲームバックエンド用 Game Cloud DB。

韓国企業は一般に AWS 依存度が非常に高く(DynamoDB, Aurora, ElastiCache, OpenSearch)、エッジDBはサイドプロジェクトと新興SaaSスタートアップで急速に採用される様相です。

28. 日本の導入事例 — Mercari · LINE Yahoo · CyberAgent · DeNA

日本主要企業のデータベース選択です。

Mercari — 中核取引に Aurora MySQL + DynamoDB。通知・キューワークロードに SQS + Lambda。検索は自社 ElasticSearch。AI 推薦に自社モデル + DynamoDB でキャッシュ。

LINE Yahoo (LY Corporation) — メッセージングは自社分散システム(自社 NoSQL + Redis クラスタ)。広告インベントリ・集計に Spanner 運用(GCP 日本リージョン)、Yahoo! 広告システムには ClickHouse を広範に使用。

CyberAgent — AbemaTV バックエンドに CockroachDB と Aurora 混用。広告入札システムには自社分散 KV + DynamoDB。ゲーム子会社は各自異なる stack。

DeNA — モバイルゲームバックエンドに Aurora + DynamoDB。一部横軸分散ワークロードは自社 Cassandra クラスタ。AI 推薦に BigQuery + Vertex AI。

SmartNews — ニュース推薦に DynamoDB + ElastiCache Redis + S3 + Athena。コンテンツメタデータに Aurora。

日本企業は韓国と似て AWS・GCP 両方のマルチクラウド採用が多く、特に広告・メディアなどグローバルワークロードで Spanner・CockroachDB の採用が韓国より積極的です。

29. マイグレーションシナリオ — Fauna から Convex / DynamoDB へ

Fauna 終了をきっかけに2025年で最もよく発生したマイグレーションシナリオは以下です。

Fauna → Convex: フルスタックreactiveアプリが主用途だったなら自然な選択。FQL → Convex TypeScript 関数、GraphQL 依存があれば Apollo Client そのまま、リアルタイム購読は Convex live query で置換。

Fauna → DynamoDB: KV / document ワークロードなら DynamoDB がコスト・性能で優位。データモデル再設計(NoSQL access pattern ベース)が必要。グローバル active-active が必要なら Global Tables。

Fauna → MongoDB Atlas Serverless: document モデルそのまま維持、FQL → MongoDB aggregation pipeline 変換。最も単純な1:1 対応経路。

Fauna → CockroachDB / Spanner: 強い一貫性 + グローバルが核心だったら。ただしSQLへのパラダイム転換コストが大きい。

PlanetScale 無料ティア終了後に最も多かったマイグレーション経路は PlanetScale → Neon / Supabase(Postgres)または PlanetScale → Aurora Serverless v2(MySQL維持)でした。

30. 2027年以降の展望 — AIワークロードとOrioleDBが変えるもの

2026年時点で今後2–3年のトレンドを予測すると以下です。

AIワークロードのデータ要件がカテゴリを再定義 — ベクトルDB(Pinecone, Weaviate, Qdrant)と pgvector 統合 Postgres(Supabase, Neon)の競争激化。マルチモーダル埋め込み、グラフ RAG、組み込み検索を1 DB に集約する流れ。

OrioleDB と cloud-native Postgres storage engine の標準化 — Supabase が買収した OrioleDB が2027年に stable になれば、伝統的な Postgres heap の限界(WAL 負荷, vacuum, freezing)を脱した新世代 Postgres が標準になる可能性。

エッジDBの書き込み分散の本格化 — Turso, D1 がマルチマスター書き込みをベータで発表しており、2027年には真の active-active エッジDBが出る可能性。CRDT ベース sync engine の一般化。

Database-as-Code の標準化 — Drizzle Kit, Atlas, Snaplet, Tinybird のようなツールが schema マイグレーション・テストデータ・プレビュー環境をコードで扱う流れ。CI/CDパイプラインに DB が1級市民として統合。

価格引き下げ圧力 — 無料ティア整理(Fauna, Xata, PlanetScale, Yugabyte)は2024–2025年のトレンドでしたが、2026年からは競争激化で再び価格引き下げ圧力。特に DynamoDB On-demand 価格引き下げ(2024.11)が口火を切りました。

31. 結論 — ワークロードがすべてを決める

エッジ・サーバーレスDBの世界は2020年以降の6年間で爆発的に拡大し、2024–2025年には初めてカテゴリ整理(consolidation)と廃業(Fauna, Xata, Yugabyte 無料終了)が起こりました。2026年5月現在、市場は次の5つの大きな束に定着しました。

  1. Cloudflareスタック — D1, Hyperdrive, KV, R2, Queues, DO。Workers中心のフルスタック。
  2. Postgres サーバーレス束 — Neon, Supabase, Vercel Postgres, Aurora Serverless v2。最大市場。
  3. エッジSQLite — Turso, D1。グローバル読み込みに最適。
  4. グローバル分散SQL — CockroachDB, Spanner, YugabyteDB。高いが必須。
  5. フルスタックreactive — Convex, Supabase Realtime。新パラダイムの可能性。

エンジニアリング判断の中核質問は変わりません — 読み込み中心か書き込み中心か、グローバルかリージョンか、強い一貫性が必要か、トラフィック変動が大きいか。この4つの質問の答えを正直に書き出せば、どのDBが合うかがほぼ自動的に決まります。

最後に、2026年の最も重要な教訓 — 「エッジDB」を導入する前に「自分のワークロードは本当にエッジが必要か」をまず問うてください。90%以上のSaaSは単一リージョンPostgres + グローバルキャッシュで十分。グローバルユーザーがいてもすべてのデータがグローバル複製される必要はありません。正直なワークロード分析がコストと複雑性を減らす第一歩です。

References

Discuss on Twitter • View on GitHub