🗄️ Vercel Storage 全13製品 — 提供企業と無料枠・有料枠の完全比較
Vercel の Storage 画面に並ぶ13製品を、提供企業の素性(上場しているか・誰の金で動いているか)と無料枠の実数値、そして「無料枠の落とし穴」まで一次情報で並べた。結論から言うと、無料枠の大きさと会社の安定性は逆相関していた。
📋 全13製品 一覧表
このセクションの3点
① Storage画面にはVercel純正とMarketplace製品が同じ場所に並ぶが、提供企業・接続方式・移行のしやすさは別に確認する必要がある
② 東京リージョンが確認できるのはPrisma Postgres、Turso、MotherDuckの3製品で、Neonは東京なしである
③ 無料枠は13製品すべてについて確認できた一方、Vercel BlobのHobby無料枠の正確な数値は未確認である
Vercel Storage画面に並ぶ13製品
ここでは製品名の見た目ではなく、誰が提供し、どこに置けて、どの経路で接続するかを同じ表で確認する。無料枠の要点は、この仕様書で一次情報として確認できた範囲だけを記載する。
| 製品 | 提供企業 | 種類 | 東京リージョン | 無料枠の要点 | 接続方式 |
|---|---|---|---|---|---|
| Global Config | Vercel | Global Config | 東京リージョン選択という項目自体がない | Hobby: 1MB、ストア1個、1プロジェクトに接続できる数1個、バックアップ保持7日 | 未確認 |
| Blob | Vercel | オブジェクトストレージ | 未確認 | Hobby無料枠の正確な数値は未確認。超過するとBlobにアクセスできなくなり、30日経過するまで復帰しない | 未確認 |
| Neon | Neon | Postgres | 東京なし | 0.5GB/プロジェクト、100 CU-hours/プロジェクト、100プロジェクト/組織 | postgres:// |
| Aurora DSQL | Amazon(AWS) | データベース | 未確認 | 毎月 最初の 100,000 DPU と 1GB ストレージが無料 | OIDC経由のみ |
| Turso | Turso | SQLite / libSQL | 東京(nrt)あり | 100データベース、5GB ストレージ、読み 5億行/月、書き 1000万行/月 | 接続文字列 |
| Upstash | Upstash | Redis / Vector / Queue / Search | 未確認 | 月 50万コマンド、256MB ストレージ、データベース1個 | 未確認 |
| Supabase | Supabase | Postgres | 未確認 | DB 500MB、ファイル1GB、アクティブなプロジェクトは2つまで | postgres:// |
| Redis | Redis Ltd | Redis | 未確認 | 30MB まで、DB 1個、共有クラウド | 未確認 |
| Nile | Nile | B2B向け Postgres | 未確認 | 1GB ストレージ、5000万クエリトークン、500コネクション、DB・テナント無制限 | 未確認 |
| MotherDuck | MotherDuck | 分析DB / DuckDB | ap-northeast-1(東京)あり | Lite: 10GB ストレージ、Pulse コンピュート 10時間/月 | 未確認 |
| Convex | Convex | バックエンドデータベース | 未確認 | Starter: DB 0.5GB、ファイル1GB、関数呼び出し 100万回/月、egress 1GB | 未確認 |
| Prisma Postgres | Prisma | Postgres | ap-northeast-1(東京)あり | 500MB ストレージ、10万オペレーション/月、50データベース | postgres:// |
| MongoDB Atlas | MongoDB | MongoDB | 未確認 | M0: 512MB ストレージ、最大 100 オペレーション/秒 | 未確認 |
読み方
「東京リージョンなし」は、Neonについて仕様書で確認できた事実である。「未確認」は、東京がないことを意味しない。確認できていないセルを、非対応と読み替えないことが重要である。Global Configは、ユーザーに最も近い場所で読む設計のため、東京リージョン選択という項目自体がない。
接続方式は製品名より先に見る
接続文字列
Neon・Turso・Supabase・Prisma Postgres
OIDC経由のみ
Aurora DSQL
接続方式が未確認
追記2で明記のない製品
→ 次のSection 2では、確認できた無料枠を容量・計算量・行数・転送・DB個数に分けて比較する。
🆓 無料枠の実数値
このセクションの3点
① 13製品の無料枠は、容量、DB・ストア数、計算量や利用量、転送・運用条件に分けて確認する
② CU-hour / オペ数 / 行数 / コマンド数 / クエリトークン / 関数呼び出し / DPU / MB は全部別単位であり、数字だけを横並びにしない
③ Vercel Blobは超過時に追加課金ではなくアクセス停止となり、Global Configはストア1個・全世界反映最大10秒という用途上の制約がある
容量は単位を保ったまま比較する
| 製品 | 無料の容量 | 補足 |
|---|---|---|
| Global Config | 1MB | Hobbyのストア最大サイズ |
| Blob | 未確認 | Hobbyプランの正確な無料枠数値(GB・オペ数)は未確認 |
| Neon | 0.5GB/プロジェクト | — |
| Aurora DSQL | 1GB ストレージ | 毎月 最初の 100,000 DPU とともに無料 |
| Turso | 5GB ストレージ | — |
| Upstash | 256MB ストレージ | — |
| Supabase | DB 500MB(共有CPU/RAM 500MB)、ファイル1GB | — |
| Redis Cloud | 30MB まで | 共有クラウド |
| Nile | 1GB ストレージ | — |
| MotherDuck | 10GB ストレージ | Liteは恒久無料 |
| Convex | DB 0.5GB、ファイル1GB | — |
| Prisma Postgres | 500MB ストレージ | — |
| MongoDB Atlas | 512MB ストレージ | RAM/vCPU 共有 |
DB・ストア・プロジェクト数と運用条件
| 製品 | 個数・上限 | 無料枠の運用条件 |
|---|---|---|
| Global Config | ストア1個、1プロジェクトに接続できる数1個 | バックアップ保持7日。書き込みの全世界反映 最大10秒 |
| Blob | Hobby 100 | 超過するとBlobにアクセスできなくなり、30日経過するまで復帰しない |
| Neon | 100プロジェクト/組織、10ブランチ/プロジェクト | 手動スナップショット1個 |
| Aurora DSQL | 未確認 | 月次請求へ自動適用 |
| Turso | 100データベース | PITR 1日 |
| Upstash | データベース1個 | — |
| Supabase | アクティブなプロジェクトは2つまで | 無料プロジェクトは1週間(7日)使われないと自動的に一時停止 |
| Redis Cloud | DB 1個 | 共有クラウド |
| Nile | DB・テナント無制限、500コネクション | — |
| MotherDuck | 未確認 | Liteは恒久無料 |
| Convex | 開発者 1〜6人 | — |
| Prisma Postgres | 50データベース | クレカ不要 |
| MongoDB Atlas | 未確認 | — |
計算量・操作量は別々の物差しである
CU-hour / オペ数 / 行数 / コマンド数 / クエリトークン / 関数呼び出し / DPU / MB は全部別単位である。CU-hourは計算資源の利用時間、オペ数はDBとのやり取り、行数は読み書きした行、コマンド数は実行コマンド、クエリトークンはNile固有の単位、関数呼び出しは関数の実行回数、DPUはAurora DSQLの利用量、MBは容量を表す。同じ数字として比較しない。
| 製品 | 無料の計算量・利用量 | 定義・条件 |
|---|---|---|
| Global Config | 未確認 | 書き込みの全世界反映 最大10秒 |
| Blob | Hobbyの正確な無料枠数値は未確認 | Simple Operations / Advanced Operationsが課金対象。ダッシュボードでの閲覧・アップロード操作もAdvanced Operationsとして課金対象 |
| Neon | 100 CU-hours/プロジェクト | オートスケール上限2CU(8GB RAM)、5分でゼロスケール |
| Aurora DSQL | 毎月 最初の 100,000 DPU | 月次請求へ自動適用 |
| Turso | 読み 5億行/月、書き 1000万行/月 | — |
| Upstash | 月 50万コマンド | — |
| Supabase | 未確認 | 共有CPU/RAM 500MB |
| Redis Cloud | 未確認 | — |
| Nile | 5000万クエリトークン | — |
| MotherDuck | Pulse コンピュート 10時間/月 | — |
| Convex | 関数呼び出し 100万回/月 | 超過 $2.20/100万回 |
| Prisma Postgres | 10万オペレーション/月 | 1回のDBとのやり取り。直接接続ではSQL 1本=1オペで、SELECT 1でも1オペ |
| MongoDB Atlas | 最大 100 オペレーション/秒 | — |
転送・履歴・停止条件
| 製品 | 転送・履歴 | 注意点 |
|---|---|---|
| Global Config | バックアップ保持7日 | 頻繁に更新するデータや更新直後の即時読み出しには使わない |
| Blob | 未確認 | 超過しても追加課金はされないが、Blobにアクセスできなくなり、30日経過するまで復帰しない |
| Neon | egress 5GB、履歴6時間(1GB上限) | — |
| Aurora DSQL | 未確認 | — |
| Turso | Sync 3GB/月、PITR 1日 | — |
| Upstash | 未確認 | — |
| Supabase | egress 5GB+キャッシュegress 5GB | 無料プロジェクトは1週間(7日)使われないと自動的に一時停止 |
| Redis Cloud | 未確認 | — |
| Nile | 未確認 | — |
| MotherDuck | 未確認 | — |
| Convex | egress 1GB | 超過 $0.132/GB |
| Prisma Postgres | 未確認 | — |
| MongoDB Atlas | 未確認 | — |
無料枠の数字だけでは用途を決めない
Vercel Blobは、無料枠の正確な数値が未確認であるだけでなく、超過するとアクセス停止になる。Global Configはストアを1個しか作れず、反映にも最大10秒かかる。容量・回数に加え、超過時と更新時の挙動を確認する必要がある。
→ 次のSection 3では、無料枠を超えた後に確認できる初の有料プランと超過単価を整理する。
💰 有料になったときの金額
このセクションの3点
① 初の有料プランと超過単価は13製品について確認できる範囲を整理し、Prisma PostgresとSupabaseは未確認のままとする
② Redis CloudはEssentialsが最低 $200/月、MotherDuckはBusinessが$250 / 組織・月 + 使用量であり、ほかの初期有料プランと段差が大きい
③ Global ConfigのReads $3.00 / Writes $5.00は公式表に単位の明記がないため、単位は未確認である
最低 $200/月
Redis Cloud Essentials
$250 / 組織・月 + 使用量
MotherDuck Business
$4.99/月
Turso Developer
初の有料プラン
| 製品 | 初の有料プラン | 月額・最低料金 | 含まれる量 |
|---|---|---|---|
| Global Config | Pro | 未確認 | 1MB、ストア数無制限、1プロジェクトに3個まで、バックアップ90日 |
| Blob | Pro | 未確認 | 未確認 |
| Neon | Launch | 従量・月額最低なし | 転送500GB込み、オートスケール16CU まで |
| Aurora DSQL | 未確認 | 未確認 | — |
| Turso | Developer | $4.99/月 | DB無制限、9GB、読み25億行、書き2500万行、Sync 10GB、PITR 10日 |
| Upstash | Pay as You Go | 未確認 | — |
| Supabase | 未確認 | 未確認 | 未確認 |
| Redis Cloud | Essentials | $0.007/時 から・最低 $200/月 | 250MB〜100GB |
| Nile | Pro | $15/月 | 5GB・1.5億クエリトークン 込み |
| MotherDuck | Business | $250 / 組織・月 + 使用量 | 内部ユーザー10人まで・サービスアカウント無制限 |
| Convex | Professional | $25 / 開発者・月 | 2500万関数呼び出し・DB 50GB 込み |
| Prisma Postgres | 未確認 | 未確認 | 未確認 |
| MongoDB Atlas | M2 | $9/月 | 2GB・RAM/vCPU 共有 |
初期費用の段差が大きい2製品
・Redis Cloud Essentialsは$0.007/時 から・最低 $200/月で、無料は30MB までである
・MotherDuck Businessは$250 / 組織・月 + 使用量で、Liteは恒久無料の10GB ストレージとPulse コンピュート 10時間/月である
・無料枠から有料へ切り替える条件と、予算承認の単位を導入前に確認する
確認できた超過単価・従量課金
| 製品 | 超過単価・従量課金 | 単位・注意点 |
|---|---|---|
| Global Config | Reads $3.00 / Writes $5.00 | 単位は未確認 |
| Blob | ストレージ $0.023/GB、Simple $0.40/100万、Advanced $5.00/100万、データ転送(iad1) $0.05/GB、Fast Origin Transfer(iad1) $0.06/GB | 公式のPricing Exampleにある超過単価の例。Hobbyの枠とは別 |
| Neon | $0.106/CU-hour、ストレージ $0.35/GB-月、転送500GB込み以降 $0.10/GB | 従量・月額最低なし |
| Aurora DSQL | $8 / 100万DPU、ストレージ $0.33/GB-月 | — |
| Turso | 9GB超過 $0.75/GB、読み超過 $1/10億行、書き超過 $1/100万行、Sync超過 $0.35/GB | — |
| Upstash | $0.2 / 10万コマンド、ストレージは1GB超過分が $0.25/GB | — |
| Supabase | 未確認 | 推測を書かない |
| Redis Cloud | 未確認 | — |
| Nile | 未確認 | — |
| MotherDuck | 使用量 | 単価は未確認 |
| Convex | 関数呼び出し超過 $2.20/100万回、egress超過 $0.132/GB | — |
| Prisma Postgres | 未確認 | 推測を書かない |
| MongoDB Atlas | 未確認 | — |
未確認は金額がないことを意味しない
料金が未確認であることは、無料であることも高額であることも示さない。Global ConfigのReads $3.00 / Writes $5.00も、単位が未確認であるため、他の単価とそのまま比較しない。
→ 次のSection 4では、製品名の背後にある提供企業の上場状況、資金、買収を確認する。
🏢 提供企業の背景と存続リスク
このセクションの3点
① この13製品の提供企業で上場しているのはAWSとMongoDBだけであり、他は非上場または情報未確認である
② Supabaseは2026-06 Series F $500M・評価 $10.5B、Tursoは累計 $7Mであり、資金規模は大きく異なる
③ NeonはDatabricks 傘下となったため会社は消えない一方、買収後に製品仕様が変わるリスクは別に見る必要がある
上場企業はAWSとMongoDBだけ
VercelのStorage画面では製品が並列に見える。しかし提供企業の公開性は並列ではない。上場しているのはAWSとMongoDBだけである。非上場企業については、資金調達額や評価額が確認できても、上場企業と同じ継続開示があるわけではない。
| 企業 | 上場 | 設立/創業者 | 資金・所有 |
|---|---|---|---|
| Amazon(AWS) | 上場 NASDAQ: AMZN | 1994 | — |
| MongoDB | 上場 NASDAQ: MDB | 2007 | — |
| Vercel | 非上場・S-1未提出 | 2015 / Guillermo Rauch | 累計 $863M・6ラウンド・33投資家。2025-09-30 Series F $300M・評価額 $9.3B(Accel と GIC が共同主導)。売上ラン・レート 約$340M(2026-03、2024年末は$144M、YoY 約84%) |
| Neon | 非上場・Databricks 傘下 | 2021 / Nikita Shamgunov, Heikki Linnakangas, Stas Kelvich | 2025-05-14 に Databricks が 約$10億で買収を発表。Databricks CEO は「Neon のDBの80%はAIエージェントが自動作成」と説明 |
| Supabase | 非上場 | 2020 / Paul Copplestone | 2025-10 Series E $100M・評価 $5B(Accel・Peak XV 共同主導、Figma Ventures 参加) → 2026-06 Series F $500M・評価 $10.5B(GIC 主導) |
| Turso | 非上場 | 旧 ChiselStrike / Glauber Costa | 累計 $7M(Series A 1回・25投資家。Upside Partnership、Blumberg Capital 等) |
| Prisma / Upstash / Redis Ltd / Nile / MotherDuck / Convex | いずれも非上場 | 未確認 | 未確認 |
資金・所有の変化
- 1
2025-05-14
Neonの買収発表
Databricks が 約$10億で買収を発表。NeonはDatabricks 傘下となった。 - 2
2025-09-30
Vercel Series F
Series F $300M・評価額 $9.3B。Accel と GIC が共同主導。 - 3
2025-10
Supabase Series E
Series E $100M・評価 $5B。Accel・Peak XV 共同主導、Figma Ventures 参加。 - 4
2026-06
Supabase Series F
Series F $500M・評価 $10.5B。GIC 主導。
資金規模は同じ意味を持たない
Supabaseの評価 $10.5B と Tursoの累計 $7M は、資金・評価の規模が異なることを示す。ただし、規模だけで機能の良し悪しや継続性を断定することはできない。上場状況、所有者、移行可能性を分けて評価する必要がある。
買収は消滅ではないが、仕様変更の契機になる
Neonの買収は、サービス提供元が突然なくなることとは異なる。Databricks 傘下になったことで会社は消えない。一方で、料金、提供リージョン、統合方針、ロードマップなどの製品仕様が変わるリスクは残る。導入時には、現在の機能だけでなく、接続文字列とデータ退避の経路を確認しておく。
→ 次のSection 5では、東京リージョンの有無と、関数とDBを同じ場所に置く意味を扱う。
🌏 リージョンとレイテンシ
このセクションの3点
① 東京リージョンが確認できたのはPrisma Postgres、Turso、MotherDuckの3製品のみである
② Neonは東京なしが確定し、他は未確認である。未確認を非対応と読み替えない
③ 関数とDBを同一リージョンに置くco-locateは、アプリとDBの往復距離を短くするための配置である
東京リージョンの確認状況
| 製品 | リージョン情報 | 東京 |
|---|---|---|
| Global Config | ユーザーに最も近い場所で読む設計 | 東京リージョン選択という項目自体がない |
| Blob | 未確認 | 未確認 |
| Neon | AWS 8拠点。us-east-1 / us-east-2 / us-west-2 / eu-central-1 / eu-west-2 / ap-southeast-1(シンガポール) / ap-southeast-2 / sa-east-1 | 東京なし |
| Aurora DSQL | 公式pricingページに記載なし | 未確認 |
| Turso | 東京(nrt)を含む(全32拠点前後・プライマリ+レプリカ構成) | 東京(nrt) |
| Upstash | pricingページでは未確認。対応プラットフォームとして AWS / GCP / FLY / Vercel の記載のみ | 未確認 |
| Supabase | 未確認 | 未確認 |
| Redis Cloud | 未確認 | 未確認 |
| Nile | Allと記載されるのみで東京の明示なし | 未確認 |
| MotherDuck | AWS 6拠点。us-east-1 / us-west-2 / eu-central-1 / eu-west-1 / ap-northeast-1(東京) / ap-southeast-2 | ap-northeast-1(東京) |
| Convex | 全プランでデータリージョン選択可と記載。東京の明示は未確認 | 未確認 |
| Prisma Postgres | eu-central-1 / eu-west-3 / us-west-1 / us-east-1 / ap-northeast-1(東京) / ap-southeast-1 | ap-northeast-1(東京) |
| MongoDB Atlas | pricingページに記載なし | 未確認 |
固定後に変えられない製品がある
Neonは作成後のリージョン変更は不可である。MotherDuckは組織は作成時に1リージョンへ固定される。どちらも、作成前に関数の実行場所とデータベースの配置を合わせて検討する。
co-locateとは何か
co-locateは、関数とDBを同一リージョンに置くことを指す。関数がリクエストを受け、DBへ問い合わせ、結果を返す経路では、関数とDBが離れるほどその間の往復が加わる。データベースだけでなく、処理を実行する場所も同時に決めるのがポイントである。
| 区間 | レイテンシ | 扱い |
|---|---|---|
| 東京↔シンガポール | 約70-80ms | 概算 |
| 東京↔us-east-1 | 約150-180ms | 概算 |
この値は概算であり、特定サービスの実測や保証値ではない。ネットワーク経路、処理時間、接続の再利用などによって実際の応答時間は変わる。導入判断では対象の構成で測定する。
実測 — 東京の関数からシンガポールのNeonを叩くと何msか
概算では判断できないので、実際に稼働している本番アプリで測った。対象は関数が東京(hnd1)・DBがNeonのシンガポール(ap-southeast-1)という構成のアプリで、同一クライアントから、DBを叩かないGETとDBを叩くPOSTの応答時間を比較した。計測日は 2026-08-08。
| 計測対象 | 1回目(コールド) | 2回目以降(ウォーム) |
|---|---|---|
| DBを叩かないGET | 353ms | 82ms / 89ms / 94ms |
| DBを叩くPOST(ログイン照会) | 1,171ms | 143ms / 150ms / 144ms |
約55-60ms
DB往復の実測コスト(東京→シンガポール)
143-150ms
DBを叩く処理の総応答時間(ウォーム)
1,171ms
初回のみ(関数起動+ゼロスケール復帰)
実測から分かったこと — co-locateは常に正解ではない
DB往復のコストは約55-60msで、DBを叩く処理の総応答は143-150msに収まった。業務システムとして十分速い。
そしてここが重要で、この構成で関数をシンガポールへ寄せると悪化しうる。DBまでの往復は数msに縮むが、日本の利用者から関数までの距離が約70-80ms増えるため、差し引きで得をしない。co-locate は「DBを何回叩くか」で判断する。1リクエストで数回なら関数は利用者の近くに置いたままでよく、十数回叩くならDBの隣に寄せる価値が出る。
コールドスタートの初回だけ 1.2秒程度かかる。Neon は5分のアイドルでゼロスケールするため、その日の最初の利用者だけが待つ形になる。常時アクセスがある業務では表に出にくいが、受検期間だけ使うアプリでは体感しうる。
→ 次のSection 6では、SQL方言・接続方式・データ退避から移行のしやすさを比較する。
🚚 移行コストと逃げやすさ
このセクションの3点
① 移行のしやすさは、SQL方言だけでなく、接続方式とデータを外へ出す経路で決まる
② NeonとPrisma Postgresはpostgres://を使い、Prisma Postgresはpg / psql / pg_dumpを含む直接TCP接続に対応する
③ Aurora DSQLはローカル接続不可・OIDC経由のみの設計で、pg_dumpによるデータ退避がそもそもできなかった実例がある
移行コストを構成する4項目
SQL方言
Postgres / SQLite
接続方式
接続文字列 / 独自SDK / IAM
データ退避
pg_dumpなど
ロックイン
独自機能への依存
仕様書で確認できた接続・退避の経路
| 製品 | SQL方言・種類 | 接続方式 | pg_dump・退避 | ロックインの見方 |
|---|---|---|---|---|
| Neon | Postgres | postgres:// | 接続文字列でローカルから接続可能 | 接続文字列を使う構成 |
| Prisma Postgres | Postgres | postgres://・直接TCP接続 | pg / psql / pg_dump が使える | 直接接続を利用可能 |
| Turso | SQLite / libSQL | 接続文字列 | 未確認 | PostgresとはSQL方言が異なる |
| Supabase | Postgres | postgres:// | 未確認 | 仕様書で退避経路は未確認 |
| Aurora DSQL | 未確認 | OIDC経由のみ | pg_dumpによるデータ退避がそもそもできなかった | 認証経路に依存 |
| Edge Config / Blob / Upstash / Redis / Nile / MotherDuck / Convex / MongoDB Atlas | 未確認 | 未確認 | 未確認 | 仕様書で未確認 |
接続できることと、逃げられることは別
アプリから接続できるだけでは、障害時や移行時の安全性を判断できない。ローカル環境からの接続、標準ツールによる退避、認証サービスが不調なときの代替経路を別々に確認する。データを読む経路と、データを持ち出す経路の両方が必要になる。
IAM / OIDCだけに依存する接続で確認すること
・認証チェーンが失敗したときに、DBへ到達する別経路があるか
・ローカルからデータを退避できるか
・引き受け先のIAMロールを誰が管理しているか
→ 次のSection 7では、今回の条件では業務データに向かない製品・使い方を理由とともに整理する。
⚠️ この中で選んではいけないもの
このセクションの3点
① Aurora DSQLは認証で締め出される実例があり、ローカル接続不可・OIDC経由のみの設計ではpg_dumpによる退避もできなかった
② Supabase無料枠は1週間(7日)未使用で自動一時停止し、Turso Postgresは完成品ではなく土台でTurso Cloudでは未提供である
③ Edge Config、Blob、Upstash、Redis、MotherDuckは用途違いとして、業務データの主データベースという要件にそのまま当てはめない
業務データの主データベースに向かない選択
| 対象 | 避ける理由 | 判断に使う事実 |
|---|---|---|
| Aurora DSQL | 認証チェーンが切れたときにDBへ到達できず、データ退避経路も持てなかった | Vercel Marketplace 経由の Amazon Aurora DSQL ×3 が全滅。ローカル接続不可・OIDC経由のみで、pg_dumpによるデータ退避がそもそもできなかった |
| Supabase無料枠 | 継続利用しない業務データでは自動一時停止が運用上の制約になる | 無料プロジェクトは1週間(7日)使われないと自動的に一時停止 |
| Turso Postgres | 実験段階であり、クラウドで選定できる提供状態ではない | 完成品ではなく土台。実用機能はあと数ヶ月。Turso Cloud では未提供で、cargo runによるソースビルドのみ |
| Edge Config / Blob / Upstash / Redis / MotherDuck | 用途違い | 業務データの主データベースとしての要件と別の用途を持つ |
Aurora DSQLで起きたこと
- 1
接続前
AWS認証段階で失敗
DBに到達する前のAWS認証段階で失敗。3アプリすべて同一エラーだった。 - 2
production ログ
同一のエラー原文
Failed to generate DSQL token: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity - 3
IAMロール
Vercel管理のAWSアカウント
引き受け先IAMロールは arn:aws:iam::276496751299:role/Vercel/access-dsql-* であり、ユーザー自身のAWSアカウント(別番号)とは無関係だった。 - 4
退避
pg_dumpを実行できない設計
DSQL はローカル接続不可・OIDC経由のみの設計だったため、pg_dump によるデータ退避がそもそもできなかった。
認証の失敗がデータ到達不能に直結した
・3アプリすべてで同一の認証エラーが発生した
・ユーザー自身のAWSアカウントではなく、Vercel管理のAWSアカウント側のIAMロールが接続条件だった
・データベースに到達できない状態で、pg_dumpによる退避もできなかった
Turso Postgresは2026-08時点の選定候補ではない
Tursoは2026-07-29に、Rust製エンジンの上へPostgres互換フロントエンドを載せる計画を発表し、実験プロジェクトpgmicroを本体にマージした。公式ブログは「今日これは完成品ではなく土台」と表現し、実用機能は「あと数ヶ月」と自己評価している。Turso Cloud では未提供で、導入方法はcargo runによるソースビルドのみである。したがって、2026-08時点の選定候補にはならない。
用途違いは製品の優劣ではない
Edge Config、Blob、Upstash、Redis、MotherDuckを避けるという判断は、これらの製品が劣っているという意味ではない。業務データの主データベースという要件と、各製品の用途が一致しないためである。
公平のための追記 — Turso の同時書き込みは前進している
2026-08-03、Turso は SQLite 書き直しエンジンの同時書き込み(BEGIN CONCURRENT)を Turso Cloud で Early Preview として公開した。MVCC による実装で、SQLite の最大 4倍の書き込みスループットと SQLITE_BUSY の解消を掲げている。ダッシュボードの設定で明示的に有効化する必要があり、正式提供ではない。
ただしこれは「SQLite は単一ライターだから業務アプリに向かない」という論拠が弱まったことを意味する。ここで避けるべきとしているのはTurso の Postgres 実装(Cloud 未提供)であって、Turso という製品全体ではない。ゼロから設計するなら、東京リージョンと無料枠5GBを持つ Turso は正当に強い選択肢である。
→ 次のSection 8では、提供企業と中国との距離という別の軸を扱う。
🌐 提供企業と中国との距離
このセクションの3点
① 「中国と関係がない」は公開情報では証明できない。言えるのは「確認した公開資料に中国系の記載がなかった」までである
② 検証可能なのはデータ保管国・サブプロセッサ・準拠法の3点で、非上場企業の資本関係は株主名簿が非公開のため追い切れない
③ Neonは提供8リージョンに中国・香港を含まない一方、Tursoはロケーション一覧に香港を含む
先に限界を明示する
・非上場企業の株主名簿は非公開で、ファンドのLP構成も開示されない。よって「中国系資本が1円も入っていない」ことは公開情報から証明できない
・この節で示すのは「確認した公開資料に中国系の記載がなかった」という事実であり、無関係であることの証明ではない
・取引先へ提出する資料では、資本関係ではなく検証可能な項目(データ保管国・サブプロセッサ・準拠法)を根拠に据える
「中国と関係がない」の4つの意味
この要件は先に定義を決めないと調査先が変わる。取引先が実務で見たいのは多くの場合4番である。
| 定義 | 何を見れば分かるか | 検証可能性 |
|---|---|---|
| ① データ保管国 | ベンダーが提供するリージョン一覧と、実際に選んだリージョン | 検証可能。自分で選択でき、証跡も残る |
| ② 資本関係 | 株主・投資家の公表情報、報道、IR | 上場企業は可能。非上場は不完全にしか追えない |
| ③ 開発拠点・従業員 | 採用ページ、法人登記、拠点一覧 | 推定にとどまり未確認が残る |
| ④ サブプロセッサ | 各社が公開するDPAとサブプロセッサ一覧 | 検証可能。データに触れる委託先を名前で確認できる |
確認できた本社・親会社・投資家
| 製品 | 提供企業・親会社 | 本社 | 確認できた主要投資家 | 中国・香港リージョン | 現時点の判定 |
|---|---|---|---|---|---|
| Neon | Neon(Databricks 傘下) | 米国 | a16z / Insight Partners / MGX(UAE政府系) / Thrive Capital / WCM / Fidelity / JPモルガンAM / QIA(カタール) / GIC(シンガポール) / Temasek(シンガポール) | なし(AWS 8拠点に中国・香港を含まない) | 確認資料に中国系の記載なし。政府系はUAE・カタール・シンガポール |
| Prisma Postgres | Prisma | 未確認 | 未確認 | なし(6拠点に中国・香港を含まない) | 資本は未確認 |
| Turso | Turso(旧 ChiselStrike) | 米国 | Upside Partnership / Blumberg Capital ほか25投資家(全容は未確認) | ロケーション一覧に香港を含む | プライマリは選択できるが、ベンダーのフットプリントに香港がある |
| Supabase | Supabase | 米国 | Accel / Peak XV(旧 Sequoia India・SEA。中国部門 HongShan は分離済み) / Figma Ventures / GIC(シンガポール) | 未確認 | 中国系の記載なし。ただし Peak XV の前身に関する説明を求められる可能性がある |
| Blob / Global Config | Vercel | 米国 | Accel / GIC(シンガポール)。累計 $863M | 未確認 | 中国系の記載なし |
| Aurora DSQL | Amazon(NASDAQ: AMZN) | 米国 | 上場 | AWS は中国リージョンを持つが別法人が運営し、通常のグローバルアカウントからは利用できない | 上場企業で継続開示がある |
| MongoDB Atlas | MongoDB(NASDAQ: MDB) | 米国 | 上場 | 未確認 | 上場企業で継続開示がある |
| MotherDuck | MotherDuck | 米国 | 未確認 | なし(AWS 6拠点に中国を含まない) | 資本は未確認 |
| Upstash | Upstash | 未確認 | 未確認 | 未確認 | 未確認 |
| Redis | Redis Ltd | 未確認 | 未確認 | 未確認 | 未確認 |
| Nile | Nile | 未確認 | 未確認 | 未確認(「All」表記のみ) | 未確認 |
| Convex | Convex | 未確認 | 未確認 | 未確認(リージョン選択可の記載のみ) | 未確認 |
政府系ファンドは中国系ではない
Databricks の株主に含まれる政府系ファンドは MGX(アラブ首長国連邦)・QIA(カタール)・GIC と Temasek(シンガポール)である。確認した公開資料に中国系ファンドの記載はない。非上場企業ではあるが、規模が大きいため資金調達が報道で追える点は、小規模な非上場企業より検証しやすい。
データ保管国で見ると差がはっきりする
資本関係が追い切れないのに対して、データが物理的にどの国に置かれるかは自分で選べて検証できる。この観点では Neon と Prisma Postgres と MotherDuck が明確で、提供リージョンの一覧に中国も香港も含まれていない。中国法の管轄下へデータが渡る経路が構造的に存在しないという説明ができる。
Turso はロケーション一覧に香港を含む。プライマリを東京にすれば香港は使われないが、ベンダーのフットプリントとして存在するため、取引先の質問状には一行必要になる。これは製品の優劣ではなく、説明コストの差である。
取引先に提出するなら6列でまとめる
本社・親会社
所在国と資本の親子関係
主要投資家
確認できた範囲のみ
データ保管国
選択したリージョン
サブプロセッサ
DPAの添付一覧
準拠法・裁判管轄
契約書の条項
確認日
調査した日付
この要件は選定を動かした
中国との距離を条件に加えると、Neon がむしろ有利になる。親会社が Databricks で調達が報道で追え、確認できた政府系ファンドは中東とシンガポールであり、提供8リージョンに中国も香港も含まない。逆に Turso は、香港ロケーションを持ち、かつ累計 $7M の非上場企業で株主の全容が追えないため、この条件下では説明コストが上がる。無料枠の大きさとは別の軸で差がついた。
→ 最後のSection 9では、ここまでの全条件を踏まえた選定を行う。
✅ 選定 — webthqui と CRM の答え
このセクションの3点
① 実測で 143-150ms に収まったため、東京リージョンを持たない Neon でも応答速度は問題にならない
② 中国との距離という条件が加わったことで、親会社を追える Neon が有利になり、香港ロケーションを持つ Turso は説明コストが上がった
③ Postgres を選ぶ判断は Turso を捨てる判断ではなく、Turso Postgres の完成を待てる判断である
選定の前提(実際の構成)
| アプリ | 旧DB | スキーマ | 最終デプロイ | 用途 |
|---|---|---|---|---|
| webthqui | Aurora DSQL(削除済み) | Postgres 10テーブル | 44日前 | ストレスチェック受検 |
| sougourhinricrm | Aurora DSQL(削除済み) | Postgres 25テーブル・CREATE INDEX ASYNC 40箇所 | 73日前 | 社内CRM |
| webthqv2 | Neon シンガポール(稼働中・関数は東京) | — | 10日前 | 構成の参照元。触らない |
データ量は無料枠の判断材料にならない
THQ受検1件は144問で、1件あたり概算7-10KBである。年500人なら年3-5MB、10年運用しても50MB程度にとどまる。CRMの25テーブルも顧客数千件で数MBの規模である。ファイルはすでにオブジェクトストレージへ逃がしている。0.5GB の無料枠は実データの約100倍の余裕があり、5GB や 10GB という容量差は使い切れない。よって容量で選ぶ意味がない。
判定 — 全て Neon(シンガポール)で揃える
| アプリ | 選定 | 関数リージョン | 理由 |
|---|---|---|---|
| webthqui | Neon(ap-southeast-1 シンガポール) | 東京(hnd1) のまま | 既存の Postgres スキーマをそのまま使える。webthqv2 と同一構成で実測 143-150ms が確認済み。オペレーション数の上限がない |
| sougourhinricrm | Neon(ap-southeast-1 シンガポール) | 東京(hnd1) のまま | 毎日使いクエリ数が多いため、オペレーション数の上限がない側が安全。CREATE INDEX ASYNC 40箇所を通常の CREATE INDEX に戻すだけで移植できる |
| webthqv2 | 現状維持(Neon) | 東京(hnd1) | 稼働中で無傷。これが構成の参照元になる |
なぜ東京リージョンを持つ Prisma Postgres ではなく Neon か
当初は受検アプリに Prisma Postgres の東京リージョンを推した。実測と要件追加で判断が変わった。
第一に、東京にDBが無くても実測 143-150ms で足りていた。第二に、Prisma には10万オペレーション/月という上限があり、直接接続では SQL 1本が1オペとして数えられる。第三に、中国との距離という条件で Prisma の資本情報は未確認のままだった。4アプリを1つの構成に揃えられるという運用上の利点も加わり、Neon に寄せる方が総合的に損が少ない。
中国との距離が判定を動かした
| 候補 | この条件下での評価 | 根拠 |
|---|---|---|
| Neon | 有利になった | 親会社 Databricks の調達が報道で追え、確認できた政府系ファンドはUAE・カタール・シンガポール。提供8リージョンに中国・香港を含まない |
| Turso | 説明コストが上がった | ロケーション一覧に香港を含む。累計 $7M の非上場企業で株主の全容が追えない |
| Prisma Postgres | 判断材料が足りない | 本社・資本が未確認。提供6リージョンに中国・香港を含まないことは確認できた |
上限に当たったとき何が起きるか(選定の本質はここ)
・Prisma Postgres: 10万オペレーション/月。直接接続では SQL 1本が1オペで、SELECT 1 でも1オペとして数えられる
・Vercel Blob: 無料枠を超えると追加課金ではなくアクセスが止まり、30日経過するまで復帰しない
・Supabase 無料枠: 1週間(7日)使われないと自動的に一時停止する
・Redis Cloud: 無料は30MBで、次のプランは最低 $200/月。無料と有料の段差が極端
・MotherDuck: 組織は作成時に1リージョンへ固定され、あとから変更できない
・Neon: 作成後のリージョン変更が不可。100 CU-hours/プロジェクト・月
この判定は Turso を捨てていない
- 1
今
Postgres を選ぶ
既存スキーマがそのまま動く。pg_dump で中身を持ち出せる状態を確保する。 - 2
数ヶ月後
Turso Postgres の提供状況を再評価
Turso Cloud で正式提供されたら、pg_dump と restore で移行を検討できる。 - 3
もし今 SQLite を選んでいたら
書き換えが2回発生する
35テーブルを SQLite 方言へ書き換え、Turso Postgres が出たら再度 Postgres へ戻す。自分が書いた SQLite 版が負債になる。
Postgres を選ぶ判断は、Turso を待てる判断である。逆に SQLite 方言へ書き換えると、Postgres へ戻る道が塞がる。可逆な側を先に選ぶ。
今回いちばん高くついた教訓
Aurora DSQL で失ったのはデータではなくデータへ到達する手段だった。認証チェーンが切れた時点で、課金を止めることも中身を退避することもできなくなった。したがって製品選定の最初の質問は、性能でも容量でもなく「この製品から pg_dump 相当の手段で中身を持ち出せるか」である。持ち出せない製品は、無料枠がどれだけ大きくても業務データを置く場所にはならない。
この記事の数値はすべて2026-08-08 時点の各社公式ページ、および同日に本番環境で実測した値である。無料枠の内容と資本構成は変わるため、実際に選定する時点で公式の pricing とサブプロセッサ一覧を再確認すること。
→ 未確認として残したセルは、各社公式ページで確認できた時点で追記する。