Supabase と Turso の選び方: 何を揃えたいかで決める

Supabase と Turso は、どちらもアプリのデータ置き場として候補に入ります。ただし、同じ土俵で比べすぎないほうが選びやすいです。この記事では、「何を揃えたいか」「どこまで一体化したいか」を軸に、Supabase と Turso の判断基準を整理します。

TL;DR

Supabase は、Postgres を中心に Auth・Storage・Realtime・Edge Functions までまとめやすい「アプリ基盤寄り」の選択肢です。
Turso は、SQLite 系の軽量 DB を中心に、branching や point-in-time recovery を扱いやすい「DB 基盤寄り」の選択肢です。
2 つを同じ種類のサービスとして比べると迷いやすくなります。
迷ったら、「DB 以外も一緒に揃えたいか」「まずは DB を小さく持ちたいか」で切り分けると判断しやすいです。

同じ土俵で比べすぎない

結論から言うと、Supabase は BaaS 寄り、Turso は SQLite 系 DB 基盤寄りです。

Supabase の Features では、各プロジェクトに Postgres データベースがあり、その上で Auth、Storage、Realtime、Edge Functions などを利用できる構成が整理されています。また、Auth architecture では、Auth サービス、Realtime、Storage などが単一の Postgres 基盤と連携する構造が示されています。

一方で Turso は、Welcome to Turso や Platform API を見ると、まずデータベースを作り、branching や point-in-time recovery を含めて DB を運用する発想が前面に出ています。さらに libSQL では、SQLite の系譜にある技術背景が説明されています。

つまり、比較の出発点はこうです。

Supabase: アプリに必要な周辺機能もまとめたいか
Turso: まず DB を軽く持ちたいか

この前提を先に揃えるだけで、かなり迷いにくくなります。

まずは「何を揃えたいか」で選ぶ

最初に考えるべきなのは、性能比較よりも何を一式で揃えたいかです。

判断基準	Supabase が合いやすい	Turso が合いやすい
DB 以外の機能	Auth、Storage、Realtime もまとめたい	DB を中心に組み、周辺機能は別で選びたい
データベースの前提	Postgres を軸にしたい	SQLite 系を軸にしたい
構成の考え方	アプリ基盤を一体化したい	小さく始めて必要なものだけ足したい
開発・検証	BaaS 全体を含めて進めたい	DB branching を使って試しやすくしたい
運用の分け方	なるべく少ないサービスでまとめたい	DB は DB として独立して扱いたい

この表の見方は単純です。 「DB 以外も欲しい」なら Supabase 寄り、「まず欲しいのは DB」なら Turso 寄りです。

判断基準を 4 つに絞る

1. 認証やストレージまで一緒に欲しいか

ここは最重要です。認証やファイル保存も最初から必要なら、Supabase のほうが判断しやすいです。

Supabase には Auth、Storage、Realtime、Edge Functions があり、同じプロジェクトの中で組み合わせやすいです。「ログイン」「プロフィール画像」「更新通知」まで早めに揃えたいなら、DB 単体ではなくアプリ基盤として見るほうが自然です。

逆に、認証やストレージは別サービスでもよく、今は DB だけを決めたいなら Turso が候補に入りやすくなります。

2. Postgres と SQLite 系のどちらを軸にしたいか

Supabase は Postgres が中心です。 RLS や SQL を含めて、アプリのデータモデルを Postgres ベースで考えたい場合に合います。

Turso は SQLite 系の流れにある DB を軸に考えやすいです。 Quickstart でも、まず DB を作って SQL を実行し、そこからアプリ接続へ進む流れが明快です。

ここは好みではなく、既存知識と運用前提で決めるとぶれにくいです。

Postgres で設計したい → Supabase
SQLite 系で軽く持ちたい → Turso

3. どこまで一体化したいか

「何を揃えたいか」に近いですが、実務では少し違います。ここで見るのは、サービス境界をどこまで減らしたいかです。

Supabase は、1 つのプロジェクトの中で複数機能をまとめやすいです。構成図を頭の中でシンプルに保ちたいチームには向きます。

Turso は、DB を独立した部品として扱いやすいです。 Platform API でも、database、database branches、point-in-time recovery、teams、API tokens などを API で管理できることが整理されています。そのぶん、Auth や Storage は別途選定する前提になりやすいです。

4. 開発時に欲しい運用機能は何か

Turso は Branching と Point-in-Time Recovery が判断材料になりやすいです。 branching は元 DB から別 DB を切って試しやすく、PITR は特定時点から新しい DB を復元する形です。

Supabase も Features 上で Branching や PITR が案内されています。ただ、Supabase を選ぶ理由は branching 単体より、Postgres + Auth + Storage + Realtime をどうまとめるかにあることが多いです。

そのため、運用機能だけで比較すると本質を外しやすいです。運用機能は補助線で見て、主軸はあくまで「何を一体化したいか」に置くのがおすすめです。

5 分で決めるための選定フロー

迷ったら、次の順で考えると決めやすいです。

今すぐ認証は必要ですか。
ファイル保存や Realtime も同じ基盤で持ちたいですか。
Postgres を前提に設計したいですか。
まずは DB 単体を軽く持つことを優先しますか。

判断の目安はこうです。

1 と 2 が Yes なら Supabase 寄りです。
3 が Yes なら Supabase 寄りです。
4 が Yes なら Turso 寄りです。

つまり、アプリ基盤をまとめるなら Supabase、DB を軽く独立させるなら Turso です。

Supabase が向いているケース

次のどれかに強く当てはまるなら、Supabase が第一候補です。

ユーザー認証を早く入れたい
ファイル保存も同じ基盤で扱いたい
Realtime を使う可能性がある
Postgres をそのまま中心に据えたい
できるだけ少ないサービス数でアプリを組みたい

特に、個人開発や小規模チームで「まずアプリを動かしたい」段階では、Supabase のまとまりやすさが効きます。

Turso が向いているケース

次のどれかに強く当てはまるなら、Turso を選びやすいです。

まず欲しいのは DB だけ
SQLite 系の扱いやすさを重視したい
DB branching を活かして検証したい
DB を独立した部品として運用したい
周辺機能は必要になってから別途組み合わせたい

特に、構成を小さく始めたい、あるいは DB をアプリ基盤から少し切り離して考えたい場合は、Turso の整理しやすさが出ます。

併用を考えてもよいか

はい、あります。ただし最初から併用前提にすると、設計の自由度と一緒に迷いも増えます。

たとえば、

認証は Supabase
DB は Turso
ファイル保存は別サービス

のような構成は作れます。ただ、最初の選定段階では、まずどちらを主軸にするかを決めるほうがうまく進みます。

アプリ機能をまとめる主軸 → Supabase
DB を中心に据える主軸 → Turso

この順で考えると、併用が必要かどうかもあとから判断しやすいです。

まとめ

Supabase と Turso は、同じ土俵で比べすぎないほうが選びやすいです。
Supabase は BaaS 寄りで、Postgres を中心に Auth・Storage・Realtime までまとめやすいです。
Turso は SQLite 系 DB 基盤寄りで、軽量な DB 運用や branching、PITR を軸に考えやすいです。
判断基準は「どちらが上か」ではなく、何を揃えたいか、どこまで一体化したいかです。
迷ったら、「DB 以外も今すぐ必要か」を最初の分岐にすると決めやすいです。