小さなAIアプリのDB選定：Cloudflare D1・Turso・SQLiteを使う前に見るべき5条件

AIで小さなアプリを量産できるほど、DB費用が重くなる

AIコーディング支援により、問い合わせ管理、簡易CRM、見積作成、社内検索、議事録整理などの小さな業務アプリは、以前よりかなり短時間で試作できるようになりました。

しかし、アプリを作りやすくなるほど見落としやすいのが、データベースの固定費です。1つのアプリなら月数千円でも、試作品が5個、10個と増えると、使われていないアプリの維持費がじわじわ効いてきます。

特に、AIで「まず作って試す」動きが増えると、最初から大きなPostgres環境を用意するより、低コストで小さく始められるデータベースを選ぶ価値が出てきます。その候補になるのが、Cloudflare D1やTursoのようなSQLite系クラウドDBです。

ただし、安いからすべて置き換えればよい、という話ではありません。どの業務に向き、どこから先はPostgresやSupabaseを選ぶべきかを整理しておく必要があります。

SQLite系クラウドDBが注目される理由

SQLiteは、サーバープロセスを常時立てる一般的なDBとは違い、単一ファイルとして扱える軽量なデータベースです。公式サイトでも、SQLiteはサーバーレスで設定不要、自己完結型のSQLデータベースエンジンとして説明されています。

従来は「ローカル開発や組み込み向け」という印象が強く、Webアプリ本番のDBとしては慎重に見られてきました。理由は明確です。複数サーバーやサーバーレス環境から同じDBファイルをどう扱うのか、書き込みが集中したときにどうするのか、という問題があるからです。

Cloudflare D1は、このSQLiteをCloudflare Workersと組み合わせて使えるサーバーレスSQLデータベースとして提供しています。Cloudflareの公式ドキュメントでは、D1はSQLiteベースであり、Workersからクエリできる仕組みとして説明されています。

TursoもSQLite系のクラウドDBです。公式ドキュメントでは、組み込みアプリからクラウド、エッジまで広い用途で使えるSQLiteプラットフォームとして位置づけられています。

つまり、SQLiteの軽さをクラウド上で扱えるようにした選択肢が増えてきた、ということです。

料金だけで選ばないための5条件

2026年5月16日時点の公式情報では、Cloudflare D1はWorkers Paidプランの月額課金枠の中で利用でき、D1の無料枠・有料枠には読み取り行数、書き込み行数、ストレージ、データベース数などの制限があります。D1のLimitsでは、Workers Paidプランでアカウントあたり最大50,000データベース、1データベースあたり最大10GBとされています。

Tursoは公式PricingでFree、Developer、Scaler、Teamなどのプランを提示しています。2026年5月16日時点では、Developerは月額$5.99からで、データベース数は無制限、Freeは100データベースまでとされています。

ここだけ見ると、かなり魅力的です。ただ、実務では次の5条件を見るべきです。

1つ目は、読み取り中心か、書き込み中心かです。SQLite系のクラウドDBは、読み取り中心の小さなアプリや、低頻度の更新には相性がよい一方、大量の同時書き込みを前提にするシステムでは慎重な検証が必要です。

2つ目は、SQL機能の複雑さです。SQLiteは非常に便利ですが、Postgresと同じ感覚で高度な型、拡張機能、複雑な分析クエリを前提にすると詰まることがあります。SQLiteにはSTRICTテーブルなどの仕組みもありますが、Postgresの厳密な型設計や拡張機能とは考え方が違います。

3つ目は、テナント分離です。顧客ごとにDBを分ける設計は、データ分離を分かりやすくできる可能性があります。一方で、DBが増えるほど、全DBに同じスキーマ変更を適用するマイグレーション運用が難しくなります。

4つ目は、将来の移行性です。小さく始めるDBが、事業の成長後もそのまま最適とは限りません。最初から、PostgresやSupabaseへ移す可能性を考え、ORM、マイグレーション、SQL方言の使い方を整理しておく必要があります。

5つ目は、運用者のスキルです。安いDBを選んでも、障害調査、バックアップ、マイグレーション、監視の手順が曖昧なら、後で高くつきます。低コストは、運用の軽さとセットで初めて意味があります。

どの用途ならD1やTursoを検討しやすいか

D1やTursoを検討しやすいのは、次のような用途です。

社内だけで使う軽量な業務ツール
問い合わせや申込の簡易管理
AI活用診断の試作版
小規模なデモアプリ
読み取り中心の設定管理や履歴参照
顧客ごとにデータを明確に分けたい小規模SaaSの初期検証

逆に、最初からPostgresやSupabaseを選びやすいのは、次のような場合です。

複雑な権限管理が必要
書き込み頻度が高い
集計・分析クエリが多い
外部サービス連携や認証を一体で扱いたい
管理画面、Storage、Auth、Edge Functionsなどをまとめて使いたい
顧客データの監査や運用手順を厳密にしたい

つまり、D1やTursoは「安いから標準」ではなく、「小さく試すための強い候補」として見るのが現実的です。

Optiensの見方

Optiensでは、AI活用診断や小規模業務アプリの提案時に、技術選定を価格だけでは決めません。DB選定では、少なくとも以下を見ます。

利用者数とアクセス頻度
読み取りと書き込みの比率
顧客データの分離要件
認証・権限・監査の必要性
将来の本番運用や移行可能性
代表者や担当者が運用できる範囲

たとえば、1か月だけ試すAIデモであれば、D1やTursoのような軽量DBが適していることがあります。一方で、顧客管理、請求、社内権限、長期運用が絡むなら、Supabase/Postgres系を選んだ方が結果的に安全な場合があります。

AIコーディングでアプリを作る時代は、実装より先に「作った後にいくらで維持できるか」「壊れたときに誰が直せるか」が重要になります。

小さく作る。低コストで試す。伸びたら移行できるようにしておく。この順番を守れば、AI時代の小規模アプリ開発はかなり現実的になります。