Supabase とは

いわゆる BaaS (Backend As A Service) で、シンガポールを拠点とするスタートアップによって 2020 年から提供されています。
Firebase Alternative（Firebase の代替）と謳われているので、BaaS と聞いてもピンと来ない人は Firebase に近いものだと想像してください。

代替というのはクローンではなくて、一部プロダクトの代わりになり得るだけです。
データベースは DBMS の種類すら異なるので扱い方が全く違いますが、クライアントから直にアクセスできる点は同じです。

Firebase の RDB 版のようなものがあるといいのに…、と思っていたところに現れました。
ここしばらく調べたり触ったりしてわかったことなどをまとめます。

プロダクト種類

今のところ下記の四つです。
モバイルに特化した機能はないので mBaaS ではありませんが、今後幅が広がる可能性はあります。

Database
Authentication
Storage
Edge Functions（~~まだその一部がアルファになったのみ~~）

Analytics の代替の要望や Crashlytics の代替の要望もあります。
Discussion を読むと upvotes が左右しそうな雰囲気があり、オープンに開発されている利点だと思います。
運営側との距離の近さが感じられて良いですね。

読み方

Super base を読むときと同じ発音 /suːpə beis/ だと思います。

注目度

現在はまだベータですが、すでに大変注目を集めていて企業の利用もあるようです。
猛烈な勢いは GitHub の Star 数の急増を見てもわかります。

. @supabase_io has been one of the fastest growing Open Source companies in the world for the last 4 quarters! 🌎🚀

📈 Q3 2020: 207%
📈 Q4 2020: 1,373%
📈 Q1 2021: 462%
📈 Q2 2021: 1,653%

and we're just getting started!! 💪💪💪https://t.co/kN42Z7Male
— Supabase (@supabase) July 8, 2021

上記記事の時点（おそらく Q2 が終わった頃）で 14.2K だったのがもう 17k まで増えていて、開発者たちの関心の高さが伺えます。

特徴

ドキュメントを読んだり触ったりしてわかった特徴を挙げます。

オープンソース（ホスティングあり）
- GoTrue、PostgREST といったオープンソースのツールを組み合わせている
- ベンダーロックインがない
  - ホスティングをやめたくなったら自分の環境でホストできる
使いやすい料金設定
- RDBMS を含むわりに安価
- 従量課金の部分が少なくて費用を予測しやすい
DB は素の PostgreSQL + PostgREST なので、その便利な機能を享受できる
便利なダッシュボード
Authentication のプロバイダが豊富
GitHub アカウントで始められる
- 自分でホストするなら登録すら不要
多数な言語/フレームワークに対応
- 公式サポートの他にコミュニティによる開発も活発

この他に個人的なところでは、よく使う Dart/Flutter 用の supabase パッケージがピュア Dart で作られているのが嬉しいです。¹
ネイティブ依存の Firebase のプラグインで辛みを感じたことがある人ならわかると思います。

リージョン

北南米、ヨーロッパ、アジア、オセアニアに 12 のリージョンがあります。
東京リージョンは五月頃に追加されました。

West US (North California)
East US (North Virginia)
Canada (Central)
West EU (Ireland)
West EU (London)
Central EU (Frankfurt)
South Asia (Mumbai)
Southeast Asia (Singapore)
Northeast Asia (Tokyo)
Northeast Asia (Seoul)
Oceania (Sydney)
South America (São Paulo)

2022-11-24 追記
いつ頃か把握していませんがソウルが追加されていたので更新しました。

料金

三つのプランがあります。
最新の情報や下記以外の詳細は Pricing のページをご覧ください。

※記載した差異の他に、カスタム SMTP サーバ、アクセスコントロール、サポート種類などがプランによって異なります。
※~~現在はベータ版のため~~ 将来変わることがあります。

2022-7-28 更新
見直したら変更されていたので更新しました。

プラン

Free

~~二つの organization とその各々に二つのプロジェクトを無料で持つことができるので、計四つが無料の範囲です。~~
下表のとおり制限がありますが、試したり少人数で利用したりする分には充分です。

データベース	500 MB までダウンロード 2 GB まで（アップロードは無制限）自動バックアップなし
Auth	50,000 ユーザ/月（MAU）監査証跡 1 時間
ストレージ	1 GB までダウンロード 2 GB まで（アップロードは無制限）
Edge Functions	呼び出し 50 万回まで 10 個まで
API・データベースのログ保持	1 日間
無効化	一週間の不使用で無効化
サポート	コミュニティによるサポートのみ

2022-7-28 追記
このプランではプロジェクトの数は二つとなっていますが、停止した状態では無制限です！
停止/起動して同時稼働を二つまでに抑えれば三つ以上のプロジェクトを使うことができます。

Auth は初稿時点では 10,000 ユーザが上限だったと思いますが、引き上げられたようです。
また、「MAU」と明記されています。
MAU で 5 万というのは無料にしては非常に緩い制限で良いですね。

Pro

プロジェクトあたり月額 $25 です。
~~従量課金される部分はなさそうですが、Functions はまだ料金が掲載されていなくてわかりません。~~

データベース	8 GB まで込みダウンロード 50 GB まで込み（アップロードは無制限）自動バックアップ 7 日間
Auth	100,000 MAU まで込み監査証跡 7 日間
ストレージ	100 GB まで込みダウンロード 200 GB まで込み（アップロードは無制限）
Edge Functions	呼び出し 200 万回まで 100 個まで
API・データベースのログ保持	7 日間
サポート	メールサポート

RDBMS、Auth などをひっくるめた料金としてはお手頃です。
Read/Write 数が料金に影響しないのが嬉しいところです。
予想外の高額になる心配が無用で、非正規化やカウントのために Functions を組み合わせたり Read 削減に苦労したりしなくて済みます。

10 万ユーザという制限は、モバイルアプリだとしたらちょっと人気が出ればもう超えてしまうかもしれませんが、そのくらいになると広告だけでも毎月少なくとも数万円の収益になるはずなので、従量制のプランへの移行に値するタイミングだと思います。

2022-7-28 追記
Free プランと違い、「～まで込み」と書いている部分では追加料金で制限を超えて利用できます。
Edge Functions は従量制のようには書かれていないので $25 に含まれていると思われます。

Auth は累計ユーザ数ではなく MAU だとわかりました。
累計 10 万ユーザではないので余裕があります。

Enterprise

プロジェクトあたり月額 $25 + 従量です。
従量課金の対象が Pro の制限を超えた分のみだといいのですが、そこのところは不明です。

データベース	~~\$0.125 / GB~~ 容量等は無制限自動バックアップ 30 日間（ポイントインタイム） ~~最適化 \$50～~~
Auth	1,000,000 MAU まで込みメールの上限は応相談他は無制限
ストレージ	\$0.021 / GB 転送 \$0.07 / GB 無制限
Edge Functions	無制限
API・データベースのログ保持	3 ヶ月間
サポート	年中無休のプレミアムエンタープライズサポート

2022-7-28 追記
以前は「Pay as you go」となっていたのが「Enterprise」に変わっていて、料金の見積もりは問い合わせることになっています。
ほんの一部を除いて従量制ではなくなっているので、必要な利用量を考慮した料金になるのでしょう。

上の表では他のプランと同じ項目のみを挙げていますが、他に SLA、SSO/SAML、SOC2、オンプレミスのサポートなど企業の必要を満たす内容となっています。

高くないけれど個人には安くない

アプリ個人開発者としては、ヒットしないうちから複数のアプリに月々 Pro プランの \$25 ずつを払うのは辛いので \$5 ～ 10 あたりのプランが欲しいです。

複数のアプリのデータを一つのプロジェクトで管理することも PostgreSQL の優れたセキュリティポリシーの機能によって可能だと思いますが、アプリごとのプロジェクトにするほうが管理しやすいです。

費用を抑えるには、Pro を使う段階になるまで安価な VPS などでホストするのがいいかもしれません。
バックエンドを全部自分で用意するのは手間がかかることですが、Supabase のセルフホスティング用のイメージと Docker Compose を使えばデータベース、API、認証といった一連の仕組みが簡単に出来上がって、手間を大きく省けます。

各プロダクト

ほとんどローカルで試したため、それに基づいた情報のみになります。
ウェブの UI の細かな使い勝手などは未確認なので省略しますが、海外の複数の人が素晴らしいと評価しているのを目にしたので、おそらく快適なのだろうと思います。

Database

PostgreSQL そのものなので、既に関連知識がある人はそのまま生かせます。
バージョンは、この記事を書いている時点では PostgreSQL 13.3 です。

次のものが組み合わさってクライアントから安全に直接利用できるようになっています。

PostgreSQL の行セキュリティポリシーの機能
GoTrue による認証
PostgREST（と Kong？）による REST API 化

シンプルなクエリの例

let user = await supabase.from('users').select('user_id, name')

Auth のユーザデータも PostgreSQL で管理されます。

リレーショナルデータベース

複数のテーブルを紐付けることができます。
Firestore ではできないせいで非正規化しないといけなかったり、そのために Functions を使う必要があったりしますが、RDB ではそういった苦労がありません。

また、アプリの仕様が変わっても既存データを結合して対応しやすいと思います。
Firestore では新仕様用のデータを作り直すなどの手間が発生しそうで不安を感じました。

PostgreSQL を使える利点

Firestore を学ぶことは他の NoSQL やドキュメント指向 DB と共通の部分はあるものの、Google のプロプライエタリな製品の使い方を学ぶという面があります。
また、データのエクスポート/インポートが面倒だったり、コレクション内のドキュメントをまとめて消すのも少し苦労したり、GUI ツールがほとんどなかったりします。

一方、Supabase のデータベースはオープンソースな PostgreSQL であり、それを使うための知識は Supabase を使わなくなったとしても汎用性があって生かせます。

ダンプやリストアの操作は普通の PostgreSQL のやり方が使えます。
月単位などのデータ削除も一文で簡単にできます。

関連ツールも PostgreSQL なら選べます。
無料の GUI ツールが複数あり、そういったツールは SQL の入力補完や linter のような支援機能があって便利です。
もともと RDBMS を使っている人は、普段の使い慣れたツールをそのまま使えるかもしれません。

スケール性

これは Firestore に圧倒的に分がありますね。

しかし RDB はグローバルな巨大サービスでよく利用されていますから、うまくやれば大量の利用に耐え得るはずです。
その「うまくやる」には知識等が必要になって簡単ではないですが、Supabase のホスティングを利用するならデータベースに最適化したインスタンスや他のサポートがあるので、スケーリングが必要な段階になったときにはそこに費用をかけられるだけの人気が出て使える予算が増えているはずです…。

なお、レプリケーションも PostgreSQL の通常のやり方でできると思われますが、スレーブのほうを参照する設定が PostgREST 等で可能なのかどうかは未調査で不明です。

Row Level Security

Firestore のセキュリティルールに相当するものとしては、PostgreSQL 自体の機能である RLS（Row Level Security：行単位セキュリティ）が利用されます。
この機能によってクライアントからのデータベースの直接利用が安全になります。

設定はまるで WHERE 句のような記述になります。

例：ログイン中のユーザが所属するチームのデータしか更新できないようにするポリシー

CREATE POLICY "Team members can update team details if they belong to the team."
    ON teams
    FOR UPDATE USING (
        auth.uid() IN (
            SELECT user_id FROM members
            WHERE team_id = id
        )
    );

SQL を読み書きできる知識があればセキュリティポリシーも読み書きできるのはいいですね。

このセキュリティポリシーには Firestore との大きな違いがあります。
Firestore のセキュリティルールはフィルタではないのに対して RLS はフィルタになります。

例えば上記のポリシーが設定されている場合に

SELECT * FROM teams;

という問い合わせを行うと、WHERE 句がないのにポリシーで指定した条件に該当するデータのみが得られます。
これは安全で良いですね。

そのような挙動になるのは、ポリシーの USING のところに書いた条件がクエリ時に自動追加される仕組みだからだそうです。

行単位セキュリティが有効なときは、テーブルへの問い合わせにこの式が追加されます。

先ほどの問い合わせなら

SELECT * FROM teams;
WHERE auth.uid() IN (
    SELECT user_id FROM members
    WHERE team_id = id
);

のように WHERE 句を勝手に追加してくれたというイメージだと思います。

RLS は時に難しい

いま見た例のようにシンプルなら簡単ですが、書き方によっては「infinite recursion」などのエラーが出ることがあります。
また集合関数が使えない等の制限があるようです。

しかし間違ったポリシーを設定しようとすると（ウェブの設定画面ではどう表示されるかわかりませんが）コマンドによる設定ならその場でエラーが出て気づけるので安全です。
また PostgreSQL のドキュメントは、先ほど貼ったリンクを開いて見るとわかるように MySQL などと比べて易しく書かれていて、困ったときに頼りになります。

ウェブの画面で設定するときにはセキュリティポリシーのテンプレートが用意されていますし、ドキュメントにも設定例がありますので、不慣れな人でも基本的な設定はできそうです。

クエリ

テーブル結合（埋め込み？）

外部キー制約を定義しておくことで関連するテーブルにも一緒に問い合わせることができます。

これを結合と思って使うとちょっと違っていて戸惑います。
結合ではなく埋め込みと捉えると違和感なく理解できそうです。
長くなるので詳細は省きますが、混乱する人が多そうなので別記事にするかもしれません。

　　↓
書きました。
実践的な情報をまとめています。

クエリビルダ

生の SQL を書くほうを好むせいか、クエリビルダは柔軟でなくて使いにくく感じます。
複雑なことがやりにくいです。

使いにくさは、PostgREST の機能としては可能なのに Supabase が対応していないだけだったり、JS ではできるのに Dart は未対応だったりすることもあり得ます。
そういうところを見つけて改善して PR したとき、開発に協力することは歓迎されているように感じました。
そんな関わり方もありだと思います。

複雑なクエリへの対処は

View を作って使う
ストアドファンクションを作って RPC で呼ぶ

といった方法でも行うことができます。

Realtime

データの変更を listen できる機能もあります。

ただし、セキュリティ面がまだ不十分のようで、現時点では誰が見てもいいデータにだけ用いるのが良さそうです。
上記文章から改善する意志が見えるので、そのうち解決すると思います。

2021 年 12 月追記
RLS のポリシーがリアルタイム機能にも適用されるようになったので、もう安全に使えます！

データベースの諸々

使いやすい API

どの言語にも共通しているわかりませんが、Dart では INSERT や UPDATE を行ったときの結果として、その追加や更新を反映した後のデータが返ってくるため、SELECT し直す必要がなくて便利です。

また、例外が起こらないように作られていて、レスポンスデータ内の error を見てエラーを判断できるのも扱いやすいです。

モバイルアプリでのオフライン利用

Firestore はモバイルアプリではローカルにキャッシュされてオフラインでも利用できますが、Supabase のデータベースは（今のところ）オンラインでなければ使えません。
これは対応作業が進められているようなので期待しておきましょう。

SQL インジェクション

危険な文字を使って INSERT を試みたところ、悪影響がありませんでした。
プレースホルダを利用したときのような安全な動作になるようです。

全文検索

RDB なのでもちろん外部ツールに頼ることなく可能ですが、ここに書かれているように曖昧な検索までできるようです。

where 
  to_tsvector(description) @@ to_tsquery('year <2> school');

PostgreSQL 自体の機能かエクステンションの機能だと思われます。
すごいですね。

関数で JavaScript を利用

create or replace function hello_world(name text) 
returns text as $$

    let output = `Hello, ${name}!`;
    return output;

$$ language plv8;

これも驚きました。
今まで MySQL を使うことが多くて、PostgreSQL にこんなに優れた種々の機能があるとは知りませんでした。

バックアップ／リストア

Pro 以上のプランにはバックアップが含まれていますが、自分でもバックアップするほうが安全でしょう。
また、セルフホスティングでは自分で設定しておかないと危険なのは言うまでもありません。
そのために役立つ情報がブログにありました。

丁寧にまとめられていてとても参考になりそうです。

GraphQL

2021 年 12 月の Launch Week にて、PostgreSQL の GraphQL エクステンションの発表がありました。
GraphQL まで使えるようになるなんて思っていませんでした。
Supabase/PostgreSQL の新たな魅力になりそうです。

Authentication

Netflix 製の GoTrue を fork しているようです。
元のほうは「An SWT based API」と書かれているのに対して Supabase の GoTrue は「A JWT based API」となっています。

ユーザデータの保管場所

ユーザ関連のデータも PostgreSQL で管理されていて auth スキーマにあります。

データベースのセキュリティポリシーでは、そこにあるユーザ情報と照らすことで、アクセスをログイン済みユーザに限定したり特定ユーザのみ許可したりすることが可能になっています。

例

auth.uid() = posts.creator_id
right(auth.email(), 13) = '@example.com'
auth.role() = 'authenticated'

OAuth プロバイダ

多数のプロバイダがあります。
主要どころが揃っていて助かります。

Apple
Azure
Bitbucket
Discord
Facebook
GitHub
GitLab
Google
Keycloak
LinkedIn
MessageBird
Notion
Slack
Spotify
Twitter
Twitch
Zoom
Twilio
Vonage

2022-11-24 追記
もともと 11 種類でしたが大幅に増えていたので更新しました。
今後も増える可能性があります
最新のプロバイダはこちらで確認してください。

匿名ログインは…

プロバイダがとても充実している素晴らしさと対照的に残念なのが匿名ログインがないことです。

メールアドレスによる認証を使い、メール確認を無効にして存在しない適当なメールアドレスで登録することで匿名っぽく使うことはできます。

そのようにワークアラウンド的に匿名を実現した場合、そこから Google ログイン等に切り替える方法がやや曖昧です。
もともとできなくて下記 issue で要望があり、その後可能になったのを確認したという報告が書かれていますが、公式の情報は見当たりません。
また、切り替えるにしてもメールアドレスが同じであることが条件になるようです。

匿名ログインがサポートされていないことは個人的には非常に大きな妨げになるので、今後公式にサポートされることを願います。

モバイルアプリでのログイン状態復元

Flutter 製のモバイルアプリでは、サインアップやログインをしたときの結果に含まれる JSON をどこかに保存しておいて、その後のアプリ起動時に recoverSession(json) を実行すればログイン状態に戻すことができます。

これについて自動化の要望があり、supabase_flutter という Flutter 専用パッケージにすることで実現されたようです（が最近のことなので未確認です）。

オフライン時などの復元

package:supabase_flutter ではなく package:supabase で二ヶ月以上前に試したままなので変わっているかもしれませんが、下記のような挙動でした。

ネットワーク接続がないままアプリ起動
- ログイン状態になった
ネットワーク接続はあるがサーバ（Docker コンテナ）が落ちているときにアプリ起動
- ログアウト状態になり、サーバを起動してからアプリを再起動するとログイン状態になった

もしワークアラウンドを使って匿名ログインを実現しているなら、ユーザはログインに必要な情報を持っていないため、ログアウトした表示にすると困らせてしまいます。
サーバが落ちている間だけの一時的なログイン失敗なので、ログイン時に立てたフラグによってログアウトの表示を防ぐ（ログアウト時に明示的に下げた場合のみログアウト表示にする）のが良いと思います。

Storage

つい最近べータになって追加された新機能の一部を紹介します。

ストリーミング
パブリック bucket
ディレクトリ丸ごとアップロード
セキュリティポリシーのエディタ
- Storage も PostgreSQL の RLS を利用しているようです
セルフホスティングにも対応（ローカルファイルシステム利用）

などなど…。
新機能全体は公式ブログをご覧ください。

試していませんが、この機能追加によって実用できる機能が揃ったと見受けられます。

Functions

関連する機能が複数あり、ブログによれば下記のような構成です。

PostgreSQL の Function
- データベースを操作する関数で、クライアントから呼べる
PostgreSQL の Trigger
- データベースの変更によって別のデータベース操作をトリガー
Hook
- データベースの変更をフックして他のものを呼び出す
- 種類
  - 外部の URL にアクセス
    - Launch Week II でアルファとして登場、九月にベータ予定
  - AWS Lambda / Google Cloud Run を呼び出す
    - 2021 年 Q4 予定
  - Supabase 独自のサーバレス Functions を呼び出す
    - 2021 年 Q4 に Early preview 予定

ちょっとややこしいですが、URL や外部 Functions などの呼び出しもできるようになるということですね。

もともと使える PostgreSQL の Trigger 等がありますし、非正規化のためなどの Functions 利用も不要なので、Firestore を使う場合と比べればサーバレスな Functions の必要性は薄いです。
それでもアプリ内課金用のバックエンド処理を用意したい場合など必要なケースはあるので、使いやすいものになるのを期待しています。

気になるのは、Supabase 独自の Functions もデータベース経由でしか使えないのかどうかです。
ブログの画像では Hooks に含まれているので、データ更新をフックする形でしか使えないのかもしれません。

まとめ

良い点は多すぎるので、残念に思った点のみをまとめます。

料金
- 無料の 4 プロジェクトがホビー用途のスペック
- 個人にとってはもう少し安いプランもほしい
データベース
- クエリビルダの柔軟性が低い（が View や RPC で解決できる）
- スケーラビリティは Firestore より劣る
- オフライン非対応（※）
Auth
- 匿名ログインが hacky な方法でしかできない（※）
- プロバイダの切り替えや複数利用のサポート具合が怪しい（※）
Edge Functions
- ~~まだ一部機能のみ（※）~~

このうち※印を付けた項目は時が経てば解決すると思われるものです。
それらが解決すると一層実用度が増すでしょう。

今もう試したい方は、GitHub アカウントがあれば始めることができますし、Docker の経験がある人ならローカルで簡単に触り始めることができます。

ローカル開発環境のことはこちらに書かれています。
~~ダッシュボードはローカルではまだ使えませんが作業は進められています。~~

2021-12-1 追記
ダッシュボードがローカルでも使えるようになりました！
docker-compose.yml に設定が含まれていて、コンテナ起動後にデフォルトでは http://localhost:3000/ にアクセスすれば利用できます。
https://supabase.com/docs/guides/hosting/docker

データベースの情報もまとめましたので、よろしければどうぞお読みください。

supabase_flutter パッケージのほうは uni_links などが使われているのでプラットフォームに依存していますが、ピュア Dart な supabase パッケージをベースにして Flutter での使い勝手を良くしたものなので、ネイティブの SDK をラップしただけの Firebase プラグインとは作りが異なります。 ↩

飛躍的に伸びているBaaS「Supabase」の概要と所感