Supabase・手軽に使えるBaaS型データベースプラットフォーム

takeda
2026-01-08
2026-01-08

こんにちは！

今回はBaaS（Backend as a Service）のデータベースプラットフォーム、Supabaseについて書いてみたいと思います。

最近では非エンジニアでもノーコードやローコードで簡易な業務アプリケーションを作ることが珍しくなくなってきています。そういったノーコード・ローコードと相性の良いのがBaaS（Backend as a Service）のデータベースプラットフォームです。開発者がバックエンドインフラストラクチャを構築・管理する手間が省け、フロント側から利用できるバックエンド環境を手軽に入手することが出来るのが魅力です。

きっかけ

AIワークフローツールの「Dify」で簡単なアプリを構築しようとしていた時、Difyから手軽に使えるデータベースがあるかを探していてSupabaseというのがあるのを知りました。

  • データベースを使いたいが、わざわざインフラを構築するのが面倒
  • NoSQLではなくRDMSがいい
  • ノーコードまたはローコードで利用したい

こういった視点から探していると、BaaSで提供されておりサービス登録すればすぐ使えそう、REST APIも提供されている、何ならDifyのマーケットプレイスでもツールが提供されている。ということでSupabaseが結構良さげだなとなった次第です。

Supabaseの特徴

BaaS（Backend as a Service）プラットフォーム

BaaSのプラットフォームなので、サービス登録すればすぐに利用可能な環境が手に入ります。基本的にマネージドなので面倒なインフラ構築や保守についてもあまり気を遣わず手軽に始められます。ダッシュボードにブラウザでアクセスしGUIベースでテーブル構築やレコード管理が可能、ユーザー管理や細かなアクセス権限管理の機能も備えています。

PostgreSQLベース

SupabaseはPostgreSQLベースのオープンソースプラットフォームです。PostgreSQLのもつ強力なクエリ機能やトランザクション機能、セキュリティ性能など高性能なリレーショナルデータベースを利用することが出来ます。

BaaSとして有名どころにはFirebaseもありますがそちらはNoSQLなのでSQLに慣れ親しんでいる人にとっては勝手が悪いところがありますが、その点SupabaseはRDMSベースなのでSQL利用者にも安心です。

REST APIで利用可能

SupabaseにはREST APIによるアクセス方法が用意されてます。これはPostgRESTというPostgreSQL用のRESTful APIツールによって提供されており、基本的なCRUD操作（作成/読み取り/更新/削除）を手軽にかつ安全にREST APIで操作出来るため、ノーコードやローコードのツールとの相性がとても良いです。

REST APIだけでなく、SupabaseからはJavascriptやPython用のライブラリも提供されているのでコーディング実装も容易です。また、きっかけのところでも述べたようにDify公式マーケットプレイスからはSupabaseのツール（CRUD機能の簡易ツール）も提供されています。

その他の機能

他にも様々な機能が提供されています。ユーザー認証を提供する「Auth」、S3互換のストレージ「Storage」、サーバレス関数「Edge Functions」、リアルタイム通信を実現する「Realtime」などがあります。

料金体系

Supabaseは基本的には定額制なのでプランによって月額が決まっているため毎月支払い額の予想が立てやすいです。（容量超過などには追加の課金が必要です）。

月額$0で利用できるFREEプランがあり、DB容量は500MBまでですが、簡単なものを試すだけなら無料でスタートできます。本格的に利用する場合は、PROプラン/TEAMプラン/ENTERPRISEプランなどの有料プランが用意されています。

詳しくは公式のPricingのページをご確認ください

使ってみる

FREEプランでSupabaseを使ってみましょう。


Supabaseの公式HPから「Start your project」へ進みます。


「Sign up」をクリックし、サインアップの手続きに入ります。


GitHubアカウントでのサインアップまたはメールアドレスでのサインアップが行えます。
今回はメールアドレスとパスワードによるサインアップを行いました。


サインアップを行うと上記のような画面になり確認メールが送信されてきます。


メールにある「Confirm Email Address」をクリックするとサインアップが完了し、Supabaseにログインされます。


最初の画面では組織の作成画面になります。組織名を入力し、組織の種類とプランを選択します。組織名は後で変更可能なのでとりあえずは何でも構いません。


組織が作成されると、最初に作成するプロジェクトの入力画面になります。任意のプロジェクト名を入力しデータベースのパスワードを設定します。リージョンはデフォルトで推奨リージョンが選択されています。必要に応じてSECURITY OPTIONSやADVANCED CONFIGURATIONを設定します（今回はデフォルト）。

以上で初期の設定が完了しダッシュボードが表示されます。


テーブルを作成するには、左のメニューの「Table Editor」を開き、「+ New Table」をクリックするか、初期状態では画面中央に「Create a table」のボタンがあるのでそこからテーブル作成に入ります。
※SQL Editorからクエリでテーブル作成することも出来ます。

試しに「messages」というテーブルを作成してみます。


テーブル名を入力し、カラムの設定を行います。
例として、id（自動採番）、title（varchar）、message（text）、created_at（レコード作成日・自動）を用意しました。

テーブルを作成すると、レコード操作の画面が表示されます。


Table Editorの画面上からは「insert」でレコードを登録したり、編集、削除、ソートやフィルタリングなど様々な操作が行えます。

REST APIを使うための準備

Supabaseに備わっているREST APIでテーブルを操作してみましょう。

まずREST APIでアクセスするためにエンドポイントの確認やAPI KEYの確認、およびアクセス制限の設定等を行います。

REST APIの有効化とエンドポイントの確認

Project Settings（左メニューの一番下にあります）を開きます。次にData APIの項目を開きます。


REST APIのエンドポイントURLが確認出来ます。https://[プロジェクトID].supabase.co というURLになっています。
また、Data APIが有効になっている事も確認します。

API KEYの確認

API Keysの項目を開きます。


Publishable keyとSecret keyがあります。※このほかに古いタイプのLegacy anon, service_role API keysもありますがこちらは現在非推奨。

Publishable keyは、通常のフロントエンド側からのアクセスに用いるキーです（そういう意味で公開可能キー）。RLS(Row Level Security)を有効にした状態のテーブルにアクセスするためのもので適切なアクセスポリシーを設定している事を前提に用いるキーです。今回はこちらを使用します。デフォルトで1つ発行済みですが、任意で新規発行することも出来ます。

一方のSecret keyはプロジェクトAPIも利用できるキーで、公開してはいけないタイプのキーです。こちらはサーバーサイドやバックエンドなどの公開されない領域で用いることが前提とされています。

RLS(Row Level Security)とポリシー

RLS(Row Level Security)は特定の認証ユーザに対するテーブル内の行データへのアクセスを制限するもので、PostgreSQLに備わっているセキュリティ機能です。詳細は割愛しますが条件指定しておくことで権限のないレコードの読み取り防止や不正な値の挿入・更新が出来ないようにすると言ったことが可能です。

SupabaseではRLSが有効かつポリシー設定がされているテーブルに対してのみREST APIでアクセス可能であるため、テーブルにアクセスするにはまずポリシー設定を行います。今回はREST APIの動作確認が目的なので、ひとまず全ての操作が可能なポリシーを暫定的に設定します。

※実際に使用する際は必要に応じた適切なポリシー設定を行ってください



RLSのポリシー設定はTable Editorの画面の右上の「Add RLS policy」ボタンから行います。

画面がAuthenticationの設定のPoliciesの画面に移動します。

現在何もポリシーが設定されていないので「Create policy」でポリシーを作成を開きます。

ポリシーの作成画面が開きます。


右側のテンプレートを利用して設定することも可能ですが、今回はテンプレートを使用せず次の様に設定しました。

  • Policy Name: Enable All Access　※任意のポリシー名
  • Tableon clause: public.messages　※対象テーブル
  • Policy Behavior as clause: Permissive
  • Policy Command for clause: ALL
  • Target Roles to clause: Defaults to all (public) roles if none selected　※許可対象ロール
  • using( true ) ※SELECTやDELETEを許可する条件。常に許可したいため固定でtrue。
  • Use check expression: オフ ※INSERTやUPDATEを許可する条件。今回は使用しない。

「Save policy」でポリシーに追加されます。

REST APIを叩く(まずcurlでやってみる)

INSERTをやってみましょう。curlでHTTPリクエストをかけてAPIを叩きます。

curl -X POST "https://<PROJECT_ID>.supabase.co/rest/v1/messages" \
-H "apikey: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{"title": "投稿テスト1", "message": "今日はいい天気です。"}'

INSERT なので POSTで送信します。
エンドポイントは、https://<PROJECT_ID>.supabase.co/rest/v1/messages/<テーブル名> です。
リクエストヘッダーの"apikey"にPublishable keyのAPIキーをセットします。
Content-Typeに、application/jsonを指定し、リクエストボディにjson形式で挿入したいレコードの内容を渡します。

curlコマンドの実行後、正常にレコードが挿入されているかSupabaseのTable Editorで確認しましょう。


レコードが挿入されました。

次にSELECTも試します。一覧を取得するだけならエンドポイントに対して GETするだけです。
先ほどの手順でもう1行レコードを追加してから試してみます。

# INSERTでもう一行追加
curl -X POST "https://<PROJECT_ID>.supabase.co/rest/v1/messages" \
-H "apikey: <API_KEY>" \
-H "Content-Type: application/json" \
-d '{"title": "投稿テスト2", "message": "明日もいい天気です。"}'

# SELECTで全レコード取得（ | jq はjsonを見やすくするためのものです）
curl -X POST "https://<PROJECT_ID>.supabase.co/rest/v1/messages" \
-H "apikey: <API_KEY>" \
| jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   256    0   256    0     0    272      0 --:--:-- --:--:-- --:--:--   272
[
  {
    "id": 1,
    "title": "投稿テスト1",
    "message": "今日はいい天気です。",
    "created_at": "2025-12-30T02:34:26.1942+00:00"
  },
  {
    "id": 2,
    "title": "投稿テスト2",
    "message": "明日もいい天気です。",
    "created_at": "2025-12-30T02:41:06.805372+00:00"
  }
]

2レコード分がjsonで返されました。

次に条件抽出をしてみます。条件の指定はクエリパラメーターでカラム名とフィルタ条件を指定します。指定方法が割と独特です「カラム名=演算子.値」のような感じの形式で指定します。詳しくはPostgRESTのドキュメントをご覧下さい。

パラメーター例 説明
?id=eq.2 idが2に等しい
?created_at=gt.2025-12-30 created_atが 2025-12-30 より大きい
?message=ilike.*%E6%98%8E%E6%97%A5* messageが"明日"を含む(要URLエンコード)

id=2のレコードを取得してみましょう。

# SELECTでid=2を取得
curl -X POST "https://<PROJECT_ID>.supabase.co/rest/v1/messages?id=eq.2" \
-H "apikey: <API_KEY>" \
| jq
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   128    0   128    0     0    113      0 --:--:--  0:00:01 --:--:--   113
[
  {
    "id": 2,
    "title": "投稿テスト2",
    "message": "明日もいい天気です。",
    "created_at": "2025-12-30T02:41:06.805372+00:00"
  }
]

id=2のレコードが取得出来ました。

その他の認証方法について

先ほどはAPIの認証を簡単にするため、RLSの対象ロールを「public」にしました。こうすることでAPIキーのみの認証でアクセスが可能でした。

RLSの対象ロールに「authenticated」を指定すれば、ユーザー認証されている場合のみアクセスができるように制限することが出来ます。この場合、REST APIコール時はリクエストヘッダーにAPIキーとアクセストークン(JWT)を渡す必要があり、アクセストークンは事前にAuth APIでユーザー認証をして取得したものを使用します。またアクセストークンには有効期限があるので長時間継続して利用するには期限が切れた場合にリフレッシュトークンを使用してアクセストークンの再発行が必要となります。

Auth APIの認証に用いるユーザーはSupabaseの Authentication > Users で管理されているものを使用します。

これらの具体的な使用例はまた機会あれば紹介したいと思います。

まとめ

いかがでしたか。サービス登録するだけでPostgreSQLベースのデータベースバックエンドとREST APIが利用でき、HTTPリクエストでデータベースアクセスが可能となりました。

ノーコード、ローコードの相性がとても良いデータベースサービスだと思います。

ちなみにBaaSで利用開始できるSupabaseですが、実はセルフホストで稼動させることも可能でDockerで構築することが出来ます。（今回はBaaSが目的だったので試してませんけど）

次回は、Difyからアクセスする方法などについても書いてみたいと思います。

 
© Future Spirits Co.Ltd.