さとまたwiki

🗄️ 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 ConfigVercelGlobal Config東京リージョン選択という項目自体がないHobby: 1MB、ストア1個、1プロジェクトに接続できる数1個、バックアップ保持7日未確認
BlobVercelオブジェクトストレージ未確認Hobby無料枠の正確な数値は未確認。超過するとBlobにアクセスできなくなり、30日経過するまで復帰しない未確認
NeonNeonPostgres東京なし0.5GB/プロジェクト、100 CU-hours/プロジェクト、100プロジェクト/組織postgres://
Aurora DSQLAmazon(AWS)データベース未確認毎月 最初の 100,000 DPU と 1GB ストレージが無料OIDC経由のみ
TursoTursoSQLite / libSQL東京(nrt)あり100データベース、5GB ストレージ、読み 5億行/月、書き 1000万行/月接続文字列
UpstashUpstashRedis / Vector / Queue / Search未確認月 50万コマンド、256MB ストレージ、データベース1個未確認
SupabaseSupabasePostgres未確認DB 500MB、ファイル1GB、アクティブなプロジェクトは2つまでpostgres://
RedisRedis LtdRedis未確認30MB まで、DB 1個、共有クラウド未確認
NileNileB2B向け Postgres未確認1GB ストレージ、5000万クエリトークン、500コネクション、DB・テナント無制限未確認
MotherDuckMotherDuck分析DB / DuckDBap-northeast-1(東京)ありLite: 10GB ストレージ、Pulse コンピュート 10時間/月未確認
ConvexConvexバックエンドデータベース未確認Starter: DB 0.5GB、ファイル1GB、関数呼び出し 100万回/月、egress 1GB未確認
Prisma PostgresPrismaPostgresap-northeast-1(東京)あり500MB ストレージ、10万オペレーション/月、50データベースpostgres://
MongoDB AtlasMongoDBMongoDB未確認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 Config1MBHobbyのストア最大サイズ
Blob未確認Hobbyプランの正確な無料枠数値(GB・オペ数)は未確認
Neon0.5GB/プロジェクト
Aurora DSQL1GB ストレージ毎月 最初の 100,000 DPU とともに無料
Turso5GB ストレージ
Upstash256MB ストレージ
SupabaseDB 500MB(共有CPU/RAM 500MB)、ファイル1GB
Redis Cloud30MB まで共有クラウド
Nile1GB ストレージ
MotherDuck10GB ストレージLiteは恒久無料
ConvexDB 0.5GB、ファイル1GB
Prisma Postgres500MB ストレージ
MongoDB Atlas512MB ストレージRAM/vCPU 共有

DB・ストア・プロジェクト数と運用条件

製品個数・上限無料枠の運用条件
Global Configストア1個、1プロジェクトに接続できる数1個バックアップ保持7日。書き込みの全世界反映 最大10秒
BlobHobby 100超過するとBlobにアクセスできなくなり、30日経過するまで復帰しない
Neon100プロジェクト/組織、10ブランチ/プロジェクト手動スナップショット1個
Aurora DSQL未確認月次請求へ自動適用
Turso100データベースPITR 1日
Upstashデータベース1個
Supabaseアクティブなプロジェクトは2つまで無料プロジェクトは1週間(7日)使われないと自動的に一時停止
Redis CloudDB 1個共有クラウド
NileDB・テナント無制限、500コネクション
MotherDuck未確認Liteは恒久無料
Convex開発者 1〜6人
Prisma Postgres50データベースクレカ不要
MongoDB Atlas未確認

計算量・操作量は別々の物差しである

CU-hour / オペ数 / 行数 / コマンド数 / クエリトークン / 関数呼び出し / DPU / MB は全部別単位である。CU-hourは計算資源の利用時間、オペ数はDBとのやり取り、行数は読み書きした行、コマンド数は実行コマンド、クエリトークンはNile固有の単位、関数呼び出しは関数の実行回数、DPUはAurora DSQLの利用量、MBは容量を表す。同じ数字として比較しない。

製品無料の計算量・利用量定義・条件
Global Config未確認書き込みの全世界反映 最大10秒
BlobHobbyの正確な無料枠数値は未確認Simple Operations / Advanced Operationsが課金対象。ダッシュボードでの閲覧・アップロード操作もAdvanced Operationsとして課金対象
Neon100 CU-hours/プロジェクトオートスケール上限2CU(8GB RAM)、5分でゼロスケール
Aurora DSQL毎月 最初の 100,000 DPU月次請求へ自動適用
Turso読み 5億行/月、書き 1000万行/月
Upstash月 50万コマンド
Supabase未確認共有CPU/RAM 500MB
Redis Cloud未確認
Nile5000万クエリトークン
MotherDuckPulse コンピュート 10時間/月
Convex関数呼び出し 100万回/月超過 $2.20/100万回
Prisma Postgres10万オペレーション/月1回のDBとのやり取り。直接接続ではSQL 1本=1オペで、SELECT 1でも1オペ
MongoDB Atlas最大 100 オペレーション/秒

転送・履歴・停止条件

製品転送・履歴注意点
Global Configバックアップ保持7日頻繁に更新するデータや更新直後の即時読み出しには使わない
Blob未確認超過しても追加課金はされないが、Blobにアクセスできなくなり、30日経過するまで復帰しない
Neonegress 5GB、履歴6時間(1GB上限)
Aurora DSQL未確認
TursoSync 3GB/月、PITR 1日
Upstash未確認
Supabaseegress 5GB+キャッシュegress 5GB無料プロジェクトは1週間(7日)使われないと自動的に一時停止
Redis Cloud未確認
Nile未確認
MotherDuck未確認
Convexegress 1GB超過 $0.132/GB
Prisma Postgres未確認
MongoDB Atlas未確認

無料枠の数字だけでは用途を決めない

Vercel Blobは、無料枠の正確な数値が未確認であるだけでなく、超過するとアクセス停止になる。Global Configはストアを1個しか作れず、反映にも最大10秒かかる。容量・回数に加え、超過時と更新時の挙動を確認する必要がある。

→ 次のSection 3では、無料枠を超えた後に確認できる初の有料プランと超過単価を整理する。

🏢 提供企業の背景と存続リスク

このセクションの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: AMZN1994
MongoDB上場 NASDAQ: MDB2007
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 Kelvich2025-05-14 に Databricks が 約$10億で買収を発表。Databricks CEO は「Neon のDBの80%はAIエージェントが自動作成」と説明
Supabase非上場2020 / Paul Copplestone2025-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. 1

    2025-05-14

    Neonの買収発表

    Databricks が 約$10億で買収を発表。NeonはDatabricks 傘下となった。
  2. 2

    2025-09-30

    Vercel Series F

    Series F $300M・評価額 $9.3B。Accel と GIC が共同主導。
  3. 3

    2025-10

    Supabase Series E

    Series E $100M・評価 $5B。Accel・Peak XV 共同主導、Figma Ventures 参加。
  4. 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未確認未確認
NeonAWS 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)
Upstashpricingページでは未確認。対応プラットフォームとして AWS / GCP / FLY / Vercel の記載のみ未確認
Supabase未確認未確認
Redis Cloud未確認未確認
NileAllと記載されるのみで東京の明示なし未確認
MotherDuckAWS 6拠点。us-east-1 / us-west-2 / eu-central-1 / eu-west-1 / ap-northeast-1(東京) / ap-southeast-2ap-northeast-1(東京)
Convex全プランでデータリージョン選択可と記載。東京の明示は未確認未確認
Prisma Postgreseu-central-1 / eu-west-3 / us-west-1 / us-east-1 / ap-northeast-1(東京) / ap-southeast-1ap-northeast-1(東京)
MongoDB Atlaspricingページに記載なし未確認

固定後に変えられない製品がある

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を叩かないGET353ms82ms / 89ms / 94ms
DBを叩くPOST(ログイン照会)1,171ms143ms / 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

SQLの互換性があっても、方言や拡張機能への依存は移行時に確認する。
🔌

接続方式

接続文字列 / 独自SDK / IAM

アプリの接続コードをどれだけ置き換える必要があるかを見る。
📦

データ退避

pg_dumpなど

障害や乗り換えの際に、データを自分で取得できる経路があるかを確認する。
🔒

ロックイン

独自機能への依存

データ形式、認証、SDKが提供元固有になるほど移行対象は増える。

仕様書で確認できた接続・退避の経路

製品SQL方言・種類接続方式pg_dump・退避ロックインの見方
NeonPostgrespostgres://接続文字列でローカルから接続可能接続文字列を使う構成
Prisma PostgresPostgrespostgres://・直接TCP接続pg / psql / pg_dump が使える直接接続を利用可能
TursoSQLite / libSQL接続文字列未確認PostgresとはSQL方言が異なる
SupabasePostgrespostgres://未確認仕様書で退避経路は未確認
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. 1

    接続前

    AWS認証段階で失敗

    DBに到達する前のAWS認証段階で失敗。3アプリすべて同一エラーだった。
  2. 2

    production ログ

    同一のエラー原文

    Failed to generate DSQL token: AccessDenied: Not authorized to perform sts:AssumeRoleWithWebIdentity
  3. 3

    IAMロール

    Vercel管理のAWSアカウント

    引き受け先IAMロールは arn:aws:iam::276496751299:role/Vercel/access-dsql-* であり、ユーザー自身のAWSアカウント(別番号)とは無関係だった。
  4. 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とサブプロセッサ一覧検証可能。データに触れる委託先を名前で確認できる

確認できた本社・親会社・投資家

製品提供企業・親会社本社確認できた主要投資家中国・香港リージョン現時点の判定
NeonNeon(Databricks 傘下)米国a16z / Insight Partners / MGX(UAE政府系) / Thrive Capital / WCM / Fidelity / JPモルガンAM / QIA(カタール) / GIC(シンガポール) / Temasek(シンガポール)なし(AWS 8拠点に中国・香港を含まない)確認資料に中国系の記載なし。政府系はUAE・カタール・シンガポール
Prisma PostgresPrisma未確認未確認なし(6拠点に中国・香港を含まない)資本は未確認
TursoTurso(旧 ChiselStrike)米国Upside Partnership / Blumberg Capital ほか25投資家(全容は未確認)ロケーション一覧に香港を含むプライマリは選択できるが、ベンダーのフットプリントに香港がある
SupabaseSupabase米国Accel / Peak XV(旧 Sequoia India・SEA。中国部門 HongShan は分離済み) / Figma Ventures / GIC(シンガポール)未確認中国系の記載なし。ただし Peak XV の前身に関する説明を求められる可能性がある
Blob / Global ConfigVercel米国Accel / GIC(シンガポール)。累計 $863M未確認中国系の記載なし
Aurora DSQLAmazon(NASDAQ: AMZN)米国上場AWS は中国リージョンを持つが別法人が運営し、通常のグローバルアカウントからは利用できない上場企業で継続開示がある
MongoDB AtlasMongoDB(NASDAQ: MDB)米国上場未確認上場企業で継続開示がある
MotherDuckMotherDuck米国未確認なし(AWS 6拠点に中国を含まない)資本は未確認
UpstashUpstash未確認未確認未確認未確認
RedisRedis Ltd未確認未確認未確認未確認
NileNile未確認未確認未確認(「All」表記のみ)未確認
ConvexConvex未確認未確認未確認(リージョン選択可の記載のみ)未確認

政府系ファンドは中国系ではない

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スキーマ最終デプロイ用途
webthquiAurora DSQL(削除済み)Postgres 10テーブル44日前ストレスチェック受検
sougourhinricrmAurora DSQL(削除済み)Postgres 25テーブル・CREATE INDEX ASYNC 40箇所73日前社内CRM
webthqv2Neon シンガポール(稼働中・関数は東京)10日前構成の参照元。触らない

データ量は無料枠の判断材料にならない

THQ受検1件は144問で、1件あたり概算7-10KBである。年500人なら年3-5MB、10年運用しても50MB程度にとどまる。CRMの25テーブルも顧客数千件で数MBの規模である。ファイルはすでにオブジェクトストレージへ逃がしている。0.5GB の無料枠は実データの約100倍の余裕があり、5GB や 10GB という容量差は使い切れない。よって容量で選ぶ意味がない。

判定 — 全て Neon(シンガポール)で揃える

アプリ選定関数リージョン理由
webthquiNeon(ap-southeast-1 シンガポール)東京(hnd1) のまま既存の Postgres スキーマをそのまま使える。webthqv2 と同一構成で実測 143-150ms が確認済み。オペレーション数の上限がない
sougourhinricrmNeon(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. 1

    Postgres を選ぶ

    既存スキーマがそのまま動く。pg_dump で中身を持ち出せる状態を確保する。
  2. 2

    数ヶ月後

    Turso Postgres の提供状況を再評価

    Turso Cloud で正式提供されたら、pg_dump と restore で移行を検討できる。
  3. 3

    もし今 SQLite を選んでいたら

    書き換えが2回発生する

    35テーブルを SQLite 方言へ書き換え、Turso Postgres が出たら再度 Postgres へ戻す。自分が書いた SQLite 版が負債になる。

Postgres を選ぶ判断は、Turso を待てる判断である。逆に SQLite 方言へ書き換えると、Postgres へ戻る道が塞がる。可逆な側を先に選ぶ。

今回いちばん高くついた教訓

Aurora DSQL で失ったのはデータではなくデータへ到達する手段だった。認証チェーンが切れた時点で、課金を止めることも中身を退避することもできなくなった。したがって製品選定の最初の質問は、性能でも容量でもなく「この製品から pg_dump 相当の手段で中身を持ち出せるか」である。持ち出せない製品は、無料枠がどれだけ大きくても業務データを置く場所にはならない。

この記事の数値はすべて2026-08-08 時点の各社公式ページ、および同日に本番環境で実測した値である。無料枠の内容と資本構成は変わるため、実際に選定する時点で公式の pricing とサブプロセッサ一覧を再確認すること。

→ 未確認として残したセルは、各社公式ページで確認できた時点で追記する。