supabase

Supabase .NET DevLog #17 Welcome to our weekly log for the Supabase .NET SDK 🎉 As explained in previous posts, the current priority is closing the feature gap between the SDK and the platform. We made good progress: last week, we were around 50% parity, and we're now close to 60%. That's 20+ new features (mostly Auth), all available now in the latest version, v8.9.0. There's no strict deadline, but the sooner the better. There are 100+ features to go, and while some will be trivial, others will bring their share of challenges. Hopefully, we'll keep that momentum in the weeks to come. As usual, stay tuned and happy coding!

Postgres plus auth, storage, realtime, edge functions and instant APIs, all open source. 🔗 supabase/supabase Credits: supabase/supabase #supabase #typescript #postgres

Supabaseの接続数は「掛け算」：満杯になると何から止まるか、上限の先まで試した > 対象: アクセスが増えたときの接続数が気になる方／too many clients や PGRST003 が不安な方／Prisma・SQLAlchemy・Djangoの既定値が気になる方 > 前提: Supabaseを少し触ったことがあればOK。プーラーや pg_stat_activity は、出てきたところで説明します > 所要時間: 25分 / 確認日: 2026-11-04（料金や仕様は変わります） > 続きの記事（接続が足りなくなったら、何をするか）: qiita.com > サンプルコード一式（GitHub。ラボの設定、番号つきのテスト、結果の表）: tomozilla/connection-budget-ja-demo > ビジネス編（やさしい解説・note）: note.com 「プールサイズ」（プーラーがデータベースに開く接続の最大数）を15にしたのに、データベースには30本の接続が並んでいました。その「なぜ」が分からないままでは、自分のアプリが何本使うのかも予想できません。そこで、自分のPCにNano（無料プランのいちばん小さいコンピュートサイズ）相当の上限を再現したSupabase（以下「ラボ」）を立てて、上限の先まで押してみました。ホスト版でしか分からないことは、使い捨てのプロジェクトを作って測り、同じ日に消しています。 先に、いちばん大事な3つ 危ないものから並べます。 1. トランザクションモード（接続文字列のポートが 6543 のとき）では、前のリクエストの設定が次のリクエストに残ります。 1本の接続をリクエストごとに別の人が使い回すためです。その結果、RLSで守ったはずの他人の行と、管理者ロールの権限まで見えました。容量ではなく、情報漏れの話です（→ 6章）。 2. 接続は足し算ではなく掛け算で増えます。 プール（使い回される接続のひとかたまり）は「ロール × モード」ごとに作られ、しかもトランザクションモードは設定より1本多く使います。そしてプランを上げるだけでは接続は増えません。有料の最小構成Microの上限は、無料のNanoと同じ60でした。増えるのはコンピュートサイズを上げたときで、1つ上のSmallにすると90になります（どちらも[ホスト版]で実測。→ 1〜3章、13章）。 3. 満杯になると、「新しい接続が必要なもの」から止まります。 ラボではログインが最初に壊れましたが、ホスト版のAuthは一度使われると、使い終わっても閉じずに10本ほど持ち続けるので、同じ順番になるとは限りません（→ 4〜5章）。 今日やること（5つ） 1. 自分のアプリが使うライブラリとバージョンを書き出し、1コピーが何本開くか調べる（→ 7章の表）。 2. コピー数 × ライブラリのプール と、ロール数 × モード数 × (プールサイズ + 1) を、それぞれ計算する（→ 1章）。「コピー」の意味は下の用語表に書きました。 3. pg_stat_activity を usename ごとに数えて、Supabase自身のサービスが何本使っているかを引いておく（→ 5章）。 4. 接続文字列のポートが 6543（トランザクションモード）なら、コードで SET を使っていないか確認する。使っていたら set_config(..., true) に直す（→ 6章）。 5. タイムアウトの「はしご」を揃える。とくにPrisma 7のpgアダプタには、既定の待ち上限がありません（→ 8章）。 どの章から読むか | あなた | 読む章 | |---|---| | セキュリティが気になる | 6章（セッション状態の漏れ）だけでも | | Prismaを使っている | 8章（タイムアウト）と 7章（既定のプール）。Prisma 6→7のアップグレードは8章 | | サーバーレス（Vercel、Lambdaなど） | 3章（クライアント上限）と 7章（掛け算） | | Data APIだけ使っている | 9章（PostgREST＝Data APIの中身）と 5章 | | postgres.jsを使っている | 10章（ハングの原因と対処） | | とにかく見積もりたい | 1章 → 2章 → 5章。リポジトリに、数字を入れると見積もれる計算ページも置いてあります | 読む前に：どこで測ったか 数字には、測った場所のタグを付けます。[ラボ] は自分のPC、[ホスト版] は実際のSupabaseプロジェクト、[ドキュメント] は公式ドキュメントです。 - [ラボ]: Nano相当の上限（max_connections 90、プールサイズ15、クライアント上限200）を再現した、ローカルのSupabase CLI環境です。上限を超える実験は、すべてここで行いました。 - [ホスト版]: 共有プーラーに迷惑をかけないよう、無料プロジェクトではプールサイズを3に下げ、数本のクライアントを数秒〜1分だけつないで、終了後に元へ戻しました。有料プランでしか見えない項目だけ、使い捨てのProプロジェクトを作って読み、同じ日に消しています。 - ラボのプーラー（Supavisor 2.9.12）はホスト版と同じオープンソースですが、設定まで同じとは限りません。 - 各実験は数回しか回していません。遅延の表は1マスにつき6秒を1回です。形は見えますが、細かい数字を信じすぎないでください。 用語（ここだけ先に読んでください） この記事に出てくる言葉を、先にまとめます。とくに最初の2つは、混同すると以降の話が全部ずれます。 | 言葉 | 意味 | |---|---| | クライアント接続 | アプリ（のライブラリ）が、プーラーに向かって開く接続 | | バックエンド接続 | プーラーやAPIが、PostgreSQL本体に対して開く接続。クライアント接続とは数も上限も別物です | | プーラー | アプリとPostgreSQLの間に立ち、少ない接続を使い回す中継役。Supabaseが使っているソフトの名前が Supavisor | | 共有プーラー / 専用プーラー | 共有プーラーは既定で全員が使う方。専用プーラー（PgBouncer）は有料の追加オプションで、既定では使いません | | プールサイズ | プーラーが1つのプールでPostgreSQLに開く接続の最大数。ダッシュボードの Project Settings → Database → Connection pooling で設定します（既定15） | | トランザクションモード / セッションモード | 接続文字列のポート番号で決まります。6543 がトランザクションモード、5432 がセッションモード。プーラーを通さない直接接続も5432ですが、ホスト名が db.<プロジェクトref>.supabase.co になります | | コピー | 同時に動いているアプリのプロセスのこと。Vercelの関数インスタンス、gunicornのワーカー、node cluster の各プロセス、開発中のホットリロードなど | | Nano / Micro / Small | コンピュートサイズ。Project Settings → Compute and disk で確認できます。Nanoは無料プラン | | p50 / p95 | 速い順に並べたときの真ん中が p50、遅いほうから5%の線が p95。平均より、詰まりに気づきやすい指標です | | prepared statement | ライブラリが「このクエリは解析済み」と名前を付けて、接続に覚えさせる仕組み。その接続が別のクライアントに渡ると、覚えが食い違って壊れます | 自分がどのモードか分からないときは、ダッシュボードの Connect ボタンから接続文字列を開き、ポート番号を見てください。 この記事のいちばん重い結果（6章）は、6543のときだけ起きます。 全体像：リクエストは、どこを通って「接続」になるのか !全体像：アプリのコピー → 共有プーラー（トランザクション／セッション）・専用プーラー・直接接続 → ロール×モードごとのプール → PostgreSQL。Data API、Auth、Realtime、Storage、監視は、自前のプールで直接つなぐ 図の下の帯が、見落としやすいところです。あなたのアプリが1本も接続していなくても、Data API、Auth、Realtime、Storage、監視は、それぞれ自分のぶんを使っています。 その実測は5章にあります。 --- 1. 接続は、結局何本まで使えるのか 答え： 3つの式で決まります。①バックエンドの合計 ≤ max_connections − 予約分、②クライアントの合計 ≤ プーラーの上限、③同時に使う数 = 秒間クエリ数 × 1クエリの秒数。このうち①が、いちばん先に効きます。 なぜ気にするか： この3つを混同すると、「クライアントは200まで大丈夫」と思っている間に、①の57本で先に詰まります。 !接続の予算は3つの式：バックエンドの合計、クライアントの合計、混み具合 ① バックエンド接続の合計 直接つなぐ接続 + 共有プーラーのプールが開いている本数の合計 プールは (ロール, データベース, モード) の組ごとに1つ 1つのプールが開くのは min(そのプールのクライアント数, プールサイズ) ただしトランザクションモードは プールサイズ + 1 + 専用プーラーのバックエンド接続（両方使うなら。プールサイズは、2つのプーラーに別々に効きます） + Data APIの自前のプール（10 + LISTEN用の1本 = 11） + Auth、Storage、Realtime、監視・ヘルスチェックの、それぞれの自前のプール ≤ max_connections − superuser_reserved_connections − reserved_connections Nano／Microなら 60 − 3 − 0 = 57 です。予約分の内訳は superuser_reserved_connections（3）と、PostgreSQL 17の reserved_connections（既定0）で、どちらも[ホスト版]で確認しました。 自分のプロジェクトの値は、ダッシュボードのSQLエディタで次を実行すると分かります。 show max_connections; show superuser_reserved_connections; 見落としやすいのは最後の行、つまりSupabase自身のサービスです。[ドキュメント]（Pooling and limits）も合計に含めるものとして「Auth、Storage、PostgREST、ヘルスチェッカー」を挙げています。しかもこれらは本数が固定ではなく、使われると増えて、そのまま持ち続けるものもあります（→ 5章）。 ② クライアント接続の合計 アプリの同時コピー数 × ライブラリのプールサイズ が、プーラーの上限（Nano／Microは200）を超えられません。この200はロールごとでした（→ 3章）。ただし「ロールを増やせば余裕ができる」とは読まないでください。増えるのはクライアントの枠だけで、①のバックエンドの枠は1本も増えません。 ③ 混み具合（リトルの法則） 同時に使うバックエンド数は 秒間クエリ数 × 1クエリの秒数 です。たとえば毎秒100リクエスト・1クエリ0.2秒なら20本必要で、プールが16本（既定のプールサイズ15 ＋ トランザクションモードの1本。→ 2章）しかなければ待ち行列ができます。 注意 [ドキュメント] Connection management の目安は「Data APIをよく使うならプールサイズは max_connections の約40%まで、使わないなら最大約80%」（Nanoなら24または48）。これが1つのプールではなく全部の合計に対する数字だというのは私の解釈ではなく、SupavisorのFAQに「プーラー全体の使用量を、使える接続の40%未満に保つように」と書かれています。 実際に当てはめると、既定のプールサイズ15でロールもモードも1つなら16本なので、24本の目安には収まります。超え始めるのは、ロールやモードが増えたときです（ロール2つ・モード2つなら、プールは4つ＝64本）。 あなたがやること： ①の式に自分の数字を入れて、57（または自分のコンピュートサイズの値）と比べる。 2. プールは、何の単位で作られるのか 答え： 「ロール × データベース × モード」ごとに1つずつです。さらにトランザクションモードは、設定より1本多く使います。 なぜ気にするか： プールサイズ15でも、2ロール × 2モードならプールは4つ、4 × 16 = 64本になります。足し算で見積もっていると、ここで倍以上ずれます。 [ドキュメント]（Connection management）には、こう書かれています。 > このプールサイズは、プロジェクト全体の1つの合計としてではなく、データベースのユーザー（ロール）ごとに適用されます。プーラー経由でつなぐロールのそれぞれが、この本数までの独自のプールを持つので、プーラーが開ける接続の合計は、使うロールの数に比例して増えます。 モードについても測りました。同じロールに、トランザクションモードとセッションモードのクライアントを20本ずつ同時に流します。 [ラボ] r1 backends: 31 (ポート6543 = 16本 + ポート5432 = 15本) [ホスト版] プールサイズ3で: 7 (ポート6543 = 4本 + ポート5432 = 3本) → モードごとに別のプールでした。 16 + 15 = 31なので、1つのプールサイズでは説明できません。 ロールを増やすと、こうなります[ラボ]。 ここからの「/ 87」は、ラボの上限です（ラボは max_connections を90にしてあり、予約3本を引いて87本使えます）。ホスト版のNano／Microなら、同じ表は「/ 57」になります。 | ロールの数 | ロールごとのバックエンド | 合計（ラボ、上限87） | |---|---|---| | 1 | r1: 16 | 53〜63（Supabase自身の分を含む） | | 2 | r1: 16、r2: 16 | 70〜80 / 87 で収まる | | 3 | r1: 15、r2: 16、r3: 7〜16 | 87 / 87、満杯 | → 3ロール目で上限に達しました。 1ロールずつ見れば「15本だけ」でも、掛けると超えます。 !プールはロールごとにあるので、掛け算で上限を超える 次に、表の「16」です。プールサイズ15のはずが、トランザクションモードでは16本でした。 | 入口 | プールサイズ15のときのバックエンド | |---|---| | Supavisor トランザクション [ラボ] | 16 | | Supavisor セッション [ラボ] | 15 | | PgBouncer 1.26.1（同じDBの前に置いた）[ラボ] | 15 | → トランザクションモードだけ、設定より1本多い。 [ホスト版]でもプールサイズ3でトランザクションが4本、セッションが3本でした。理由は分かりません。数本の差ですが、3ロールなら3本違い、「ぎりぎり収まる」と「あふれる」の境目になります。 注意 [ドキュメント] SupavisorのFAQに「クライアントがプーラーに接続している間は、少なくとも1本のホットな接続が維持されます」とあり、これが「+1」の正体かもしれません。確かめるため[ホスト版]でトランザクションモードのクライアントを1本だけつないで放置したところ、バックエンドは1本のまま137秒後も維持されていました（使われない接続は約2分で消えるので、これは「維持されている」ということです）。ただし「+1」と同じ仕組みかどうかは確かめられていません。 あなたがやること： ロール数 × モード数 × (プールサイズ + 1) で数える。粒度の書き方は[ドキュメント]内でも3通り（Connection managementは「ロールごと」、SupavisorのFAQは「ユーザー・DB・モードの組ごと」、ダッシュボードは「user+db」）あるので、いちばん多く数える「ロール × DB × モード」で見積もるのが安全です。 > 「ロール数」とは、自分の場合いくつか。 数えるのは、接続文字列に書いたユーザー名の種類です。ふつうのSupabaseプロジェクトなら、プーラー経由でつなぐときのユーザー名は既定で postgres の1つだけなので、ロール数は1です。バッチ用や分析用に自分で別のロールを作れば、そのぶん増えます。 > なお anon と authenticated は、ここでは数えません。supabase-js（Data API）を使うとき、PostgRESTが authenticator という1つのロールでつなぎ、リクエストごとに内部で anon / authenticated に切り替えているからです。Data APIのぶんは、式①の「Data API 11本」で別に数えています。 3. クライアント上限の200は、プロジェクト全体？ ロールごと？ 答え： ロールごとです。[ホスト版]でも確かめました。ただし、ロールを足してもバックエンドの枠は増えません。 なぜ気にするか： サーバーレスで1コピー10本（node-postgresの既定）なら、21コピー目で拒否されます。そのとき「ロールを分ける」が有効な応急処置になるか否かが変わります。 まず、上限そのものの挙動です[ラボ]。 connected 200 client 201: (EMAXCONN) max client connections reached, limit: 200 (0.5 s) → 201本目は0.5秒で拒否され、待たされません。 次に単位です。[ドキュメント]（Pooling and limits）は、この上限を「同時にプーラーへ接続できるクライアント数＝コンピュートサイズで決まる値」と説明し、ロールの話は出てきません。Proプロジェクトの設定画面にも「この値はコンピュートサイズMicroに基づいて200に固定されていて、変更できません」とあります。どちらもプロジェクト単位に読めます。読むだけでは決着しないので、[ホスト版]で測りました（クエリは1本も投げず、接続を開いて数秒持つだけ）。 | 試したこと [ホスト版] | 結果 | |---|---| | 1つのロールで215本つなぐ | ちょうど200本が成功、残りは (EMAXCONN) ... limit: 200 | | 2つのロールで150本ずつ（合計300本） | 300本すべて成功。拒否ゼロ | → 上限はロールごとでした。 設定画面の「200に固定」は、プロジェクト全体の合計ではありません。 厳密には、Supavisorのソースが数えている単位はプール、つまりロール × モードの組です。私が測ったのはロールを分けた場合で、同じロールでモードだけ分けた場合は測っていません。見積もるときは「ロールごとに200」で数えておけば、足りなくなることはありません。 ただし、ここで喜ぶのは早すぎました。同じとき、データベース側のバックエンドはこうでした。 クライアント 300本（2ロール） → バックエンド 2本 → クエリを投げていないので、バックエンドはロールごとに1本だけ。 つまりロールを足して増えるのはクライアントの枠だけで、①のバックエンドの枠（Nano／Microで57本）は1本も増えません。その300本がいっせいにクエリを投げ始めれば、今度は①で止まります。 あなたがやること： まずは1コピーあたりのライブラリのプールを減らす（これが根本です）。それでも足りず EMAXCONN が出るなら、ロールを分ける手もあります。その場合はSQLエディタでロールを作り、接続文字列のユーザー名を差し替えます。 create role batch_user login password '<自分で決めた強いパスワード>'; grant usage on schema public to batch_user; -- 必要なテーブルへの権限も grant します 接続文字列のユーザー名は batch_user.<プロジェクトref> の形になります（プーラー経由の場合）。ただしこれは混雑を①に移しただけだと理解しておいてください。 4. 満杯になると、何から止まるのか 答え： そのとき新しい接続が必要なものから止まります。「Authが先」のような固定の順番ではありません。 なぜ気にするか： 「画面は動いているのに新規ログインだけができない」という、原因の分かりにくい形で現れるからです。 3つのロールでプールを使い切り、データベースを満杯（87／87）にした状態で、ほかのサービスを呼びました[ラボ]。 !データベースが満杯になると、新しい直接接続、プーラーの新規ログイン、Authのサインインが止まる | 満杯のとき [ラボ] | 結果 | |---|---| | 新しい直接接続 | FATAL: remaining connection slots are reserved for roles with the SUPERUSER attribute（53300） | | プーラー経由の新しいログイン | (EAUTHQUERY) authentication query failed（プーラーもログイン確認に接続を1本使う） | | Authのサインイン／サインアップ | 500（Database error querying schema） | | Data API（rpc/ping） | 200（すでに開いている接続で足りた） | | Storage（アップロード、一覧） | 200（同上） | → すでに接続を持っていたサービスは動き続け、新しく要るものだけが落ちました。 この順番は環境によって変わります。別の回に2ロールだけで満杯にしたときは、PostgRESTが新しい接続を必要とした瞬間に、Data APIが 503 PGRST000 を返しました（9章に出てくる 504 PGRST003 とは別物です。PGRST003 はプールが埋まっていて待ちきれなかったとき、PGRST000 はそもそもデータベースにつなげなかったときに出ます）。つまり「満杯ならData APIは503」とも「満杯ならAuthが先」とも言えません。 注意 [ホスト版] ラボのAuthは接続を持っていなかったので先に倒れましたが、ホスト版のAuthは一度使われると10本ほど温めて持っています（→ 5章）。そのためホスト版で同じ順番になるとは限りません。ホスト版を満杯にする実験はしていないので、ここは「ラボの順番をそのまま当てはめてはいけない」という注意までです。 もう1つ。重いクライアントが止まったあとも、サインインは約1分のあいだ HTTP 500 を返し続けました（62秒の時点でプーラーが1本手放して、やっと 200 に戻りました）。接続はすぐには戻りません（→ 11章）。 あなたがやること： 監視は「エラーが出たか」ではなく「新規ログインが通るか」を見る。具体的には、テスト用アカウントで定期的にサインインを試す外形監視（UptimeRobotのような外部サービスや、小さな定期ジョブ）を1つ置くのが手軽です。1つのロールの使いすぎが、ほかのロールやAuthまで巻き込みます。 5. Supabase自身のサービスは、何本使うのか 答え： 何もしていないときは3〜4本ですが、使われると増えます。[ホスト版]でAuthは9〜10本、Storageは8本まで増え、Storageは返しませんでした。 なぜ気にするか： 57本のうち8本が恒久的に減るなら、見積もりが8本ずれます。 まず、何もしていないときです。 表に出てくるロール名は、authenticator がData API（PostgREST）のもの、supabase_admin がSupabaseの管理・監視用、pgbouncer はプーラーがログイン確認に使うものです（名前はPgBouncer由来ですが、共有プーラーのSupavisorもこのロールを使います）。 | 環境 | 何もしていないときの使用数 | |---|---| | [ホスト版] Free／Nano（2026-11-03） | 4本（authenticator 1、pgbouncer 1、supabase_admin 2）。空きは 57 − 4 = 53本 | | [ホスト版] Pro／Micro（作りたて、2026-11-04） | 3本（authenticator 1、pgbouncer 1、supabase_admin 1） | | [ラボ] 全サービス起動 | 36本（Supavisor自身29本 + 7本）。空きは 87 − 36 = 51本（ラボは max_connections 90、予約3本を引いて87） | ラボの「Supavisor自身29本」は、プーラーをデータベースと同じ場所で動かしているラボだけの分です。ホスト版にはこの29本はありません。 → 空きは53本と51本でほぼ同じなので、ラボはホスト版の代わりとして使えます。 ここで、Proプロジェクトを作って分かった大きなことが1つあります。Microの max_connections は、Nanoと同じ60でした。 つまり、プランを有料にするだけでは接続は増えません。 増えるのはコンピュートサイズを上げたときです。同じプロジェクトをMicroからSmallに上げて測り直すと、こうなりました[ホスト版]。 | | Micro | Small | |---|---|---| | max_connections | 60 | 90 | | プーラーのクライアント上限 | 200 | 400 | | プールサイズの既定 | 15 | 15のまま | → 接続もクライアント枠も増えますが、プールサイズは据え置きです。 大きいインスタンスにしても、プールは自分で広げる必要があります。 次に、使ったあとです。作りたてのプロジェクトはAuthもStorageも0本なので、そこへサインインを40本同時に、別の回に公開バケットへのリクエストを40本同時に投げ、usename ごとに数えました。 | サービス [ホスト版 Pro] | 何もしていないとき | 負荷のあと | そのあと | |---|---|---|---| | Auth（supabase_auth_admin） | 0本 | 9〜10本 | 約1分で0本に戻った（46秒では10本、61秒で0本） | | Storage（supabase_storage_admin） | 0本 | 8本 | 14分後も8本のまま | → Authは借りて返すが、Storageは持ち続ける。 ファイルを1度でも配信したら、57本のうち8本は戻らないものとして見積もってください。 注意 [ドキュメント] SupavisorのFAQには「Storageサーバーも独自の user+db+mode の組み合わせとしてSupavisorを使う」とありますが、私が測ったプロジェクトではStorageの接続の application_name は Supabase Storage API で、プーラー経由（Supavisor）ではありませんでした。1プロジェクト・1回の観察なので断定はしません。 あなたがやること： 自分のプロジェクトで下のSQLを流し、式①から「サービスの分」を先に引く。 select usename, state, count(*) from pg_stat_activity where backend_type = 'client backend' and pid <> pg_backend_pid() group by 1, 2; 6. セッションの状態は、次のクライアントに残るのか（安全の話） 答え： 残ります。 その結果、他人の行と管理者ロールの権限が見えました。これがこの記事でいちばん重い結果です。 なぜ気にするか： RLSで守っているつもりのテーブルが、設定を1つ書き忘れただけで他人に見えるからです。可用性ではなく、情報漏れです。 [ドキュメント]（Connecting to Postgres）は、こう書いています。 > セッションレベルの状態は、トランザクションの間で失われます。これは set と reset、セッションレベルのアドバイザリロック、listen と notify、一時テーブルが対象です。 「失われる」と読むと、動かなくなるだけで危なくはなさそうに思えます。ところが私が測ったのは、消えるのではなく、次のクライアントに残るほうでした。トランザクションモードでは1本のバックエンドをクエリごとに別のクライアントが使い回すので、前の人の設定がそのまま引き継がれるのです。 | 操作 | プーラー（トランザクション）[ラボ] | 直接 | |---|---|---| | set_config('app.user','alice',false)（セッション全体） | 次のクライアントに8回中8回漏れた | 0回 | | set_config(..., true)（トランザクション内だけ） | 漏れない | 漏れない | | SET statement_timeout = 0 | 次のクライアントも0（ガードレールが静かに外れる） | 漏れない | | セッションのアドバイザリロック | クライアントが去っても保持 | 保持しない | | 名前つきprepared statement | prepared statement "q1" already exists | OK | | LISTEN/NOTIFY | 通知なし | 通知あり | → トランザクション内だけの設定（第3引数 true）以外は、すべて漏れました。 設定が漏れるだけなら地味に見えます。しかし、RLSのポリシーが owner = current_setting('app.user', true) を信じる作りだと、行が漏れます。 !トランザクションモードで、リクエストAの設定が、次のリクエストBに残る プーラー（トランザクション）: A (alice, set_config(...,true)) : alice の行 B (トランザクション内だけの設定のあと) : 何も見えない ← 安全 A (alice, set_config(...,false)) : alice の行 B (ユーザーの設定を忘れたリクエスト) : alice の行が見える ← 漏れた A (管理作業: SET ROLE r_admin) : alice, bob B (ふつうのリクエスト) : r_admin として、alice と bob が見える 直接: B は、どちらも何も見えない → SET ROLE は権限ごと漏れます。 管理者ロールに切り替えたあとそのバックエンドを受け取ったリクエストが、RLSを無視する r_admin として動きました。 対照としてData APIも確かめました。PostgRESTはリクエストごとの設定を、そのリクエストのトランザクションの中だけに入れます。2人のユーザーで40本の混ぜたリクエストを同時に流したところ、他人のデータを受け取ったのは0件でした。つまり、この問題は「プーラーを使うと必ず起きる」のではなく、設定の入れ方で決まります。 あなたがやること： トランザクションモードでは SET を使わない。リクエストごとにトランザクションを開き、その中で set_config(..., true) を使う。既存コードの SET と SET ROLE を今日grepしてください。 7. ライブラリは、1コピーで何本開くのか 答え： 10本前後が多いものの、バージョンで変わります。実際に動かして数えるしかありません。 なぜ気にするか： ②の式の「ライブラリのプールサイズ」がここで決まり、プロセス数と掛け算になるからです。 | ライブラリ（バージョン） | 既定のプール | 20〜30並列での実測 [ラボ] | |---|---|---| | node-postgres 8.23.1 Pool | max 10 | 10 | | postgres.js 4.0.0 | max 10 | 10 | | Drizzle | 自前のプールなし。ドライバのもの | （pg: 10） | | Prisma 6.19.3 | 物理コア数 × 2 + 1 | 21（10コアのMac。サーバーレスでは割り当てられたCPU数で変わるので、実測してください） | | Prisma 7.10.1 + @prisma/adapter-pg | pgドライバ（max 10） | 10 | | SQLAlchemy 2.1.6 | pool_size 5 + max_overflow 10 | 15（使い終わったあとも5本残る） | | psycopg_pool 3.3.3 | min_size 4、max_size = min_size | 4 | | Django 5.2.18（既定） | プールなし。処理中のスレッド1つにつき1本 | 20（20スレッドで） | | Django 5.2.18 OPTIONS pool=True | psycopg_poolの既定 | 4 | → 同じPrismaでも、メジャーバージョンの間で21から10に変わりました。 ブログ記事で見た数字には、必ずバージョンが付いているか確認してください。 掛け算も測りました[ラボ]。node-postgresの Pool(max 10) を持つコピー（プロセス）を増やすと、直接接続のバックエンドは1つで10、3つで30、5つで50でした（この回だけ、50本を観察するために max_connections を150に上げています）。5コピーでNanoの上限に迫ります。 gunicornのワーカー、node cluster、開発中のホットリロードで、気づかないうちに増えます。一方、プーラー経由なら5プロセスの50クライアントは16本のバックエンドに収まりました。 あなたがやること： 自分のライブラリとバージョンで1コピーの本数を数え、コピー数 × を計算する。 8. 待たされる時間に、上限はあるのか 答え： あります。しかも何段も重なっていて、いちばん短いものが先に効きます。そしてPrisma 7のpgアダプタとnode-postgresには、既定の上限がありません（無限に待ちます）。 なぜ気にするか： 上限がばらばらだと、どこで失敗するかが予想できません。上限がないと、詰まったときに止まりません。 まず、プーラー側です[ラボ]。 - トランザクションモード（プール15）: 18クライアントが30秒ずつ保持 → 16本が動き、2本は待って、全部終わるまで60秒。17クライアントが65秒ずつ保持 → 待っていた1つはちょうど60秒で (ECHECKOUTTIMEOUT) ... after 60000ms in Transaction mode。 - セッションモード（18クライアント、プール15）: 3本が0秒で (EMAXCONNSESSION)。待たされません。 → トランザクションモードは60秒待ってから落ち、セッションモードは即断られます。 この60秒は、計算で予想できます。ここでの「閉じたループ」とは、1つ終わったら次を投げるクライアントのことです（逆に、前が終わるのを待たずに一定のペースで届くのが「オープンループ」で、実際のユーザーの流入はこちらです）。 閉じたループなら、1クライアントの待ちはおおよそ (クライアント数 − バックエンド数) ÷ バックエンド数 × クエリの秒数 になります。そこで199クライアントを同時に走らせ、バックエンド16本に対してクエリの長さだけを変えました。計算上は、クエリが5秒を超えたあたりで待ちが60秒に届くはずです。 | クエリの時間 [ラボ] | 予想の待ち（キュー時間） | 実測のp50（待ち + 実行、成功分のみ） | 結果 | |---|---|---|---| | 4.5秒 | 51.5秒 | 54.1秒 | 551件が成功、エラーなし | | 5.5秒 | 62.9秒 | 60.6秒 | 464件が成功、46件が ECHECKOUTTIMEOUT（510件中46件、約9%） | → 「5秒あたりが境目」という予想どおりでした。 式で予想できるということは、事前に避けられるということです。 次に、ライブラリ側です[ラボ、直接接続]。 | ライブラリ | 接続を待つときの既定 | 確かめたこと | |---|---|---| | node-postgres Pool | 無制限（connectionTimeoutMillis: 0） | プール1本・3秒のクエリで、2本目は6.0秒、3本目は9.0秒まで待った。connectionTimeoutMillis: 2000 を付けると2.0秒で timeout exceeded when trying to connect | | Prisma 6 | pool_timeout 10秒 | connection_limit=1 で3秒のクエリ5本: 4本目が10.0秒で P2024 | | Prisma 7 + @prisma/adapter-pg | なし | プール1本、3秒のクエリ5本: 5本目まで15.1秒待って全部成功。connectionTimeoutMillis: 2000 で2.0秒で失敗 | | psycopg_pool | 30秒 | timeout=4 で PoolTimeout | | SQLAlchemy | pool_timeout 30秒 | pool_timeout=2 で QueuePool limit ... timed out | | postgres.js | connect_timeout 30秒 | 接続待ちの上限は見つけていない | | Django 5.2 pool=True | psycopg_poolの既定（4本、30秒） | 終わりに connection.close() する形なら20スレッド×2秒が10.1秒で成功。閉じないスレッドが4本いると、他16本が OperationalError | → Prisma 6からアップグレードする方は、ここがいちばん大事です。 6にあった10秒の安全網（pool_timeout）が7（pgアダプタ）では既定でなくなり、待ちが無制限になります。PrismaPg に connectionTimeoutMillis を必ず渡してください。 import { PrismaPg } from '@prisma/adapter-pg' const adapter = new PrismaPg({ connectionString: process.env.DATABASE_URL, connectionTimeoutMillis: 5000, // これがないと、詰まったとき無限に待ちます }) !待ち時間のはしご：anonの3秒、authenticatedの8秒、PostgRESTの10秒、Prismaの10秒、30秒、Supavisorの60秒、pgは無制限 ロール側の既定も、同じはしごの一部です。[ドキュメント]（Timeouts）によると anon は3秒、authenticated は8秒、service_role はなし（未設定なら authenticator の8秒）、postgres はロールごとの設定がなく既定のグローバルタイムアウトで2分に制限されます。[ホスト版]で pg_settings を読むと statement_timeout は確かに 120000、つまり2分でした。管理用のスクリプトやバッチを postgres でつないでいるなら、はしごのいちばん下は2分です。 注意 [ラボ] 到着が止まらない「オープンループ」では、話がさらに厳しくなります。1リクエストごとに新しい接続を開く形で毎秒200回（処理能力の約150回を超える）を流すと、4秒でクライアントが200に達し、以降は到着の約4分の1が (EMAXCONN) で拒否されました。閉じたループは待つのが上手なので、過負荷を隠します。つまり、自分で回す負荷テストが平気でも、実際のユーザー流入では拒否が出ることがあります。 あなたがやること： 自分のタイムアウトを1枚の表にして、いちばん短いものがどこか確かめる。Prisma 7なら connectionTimeoutMillis を今日足す。 9. Data APIは、何本使うのか 答え： 11本（プール10本 + LISTEN 用1本）です。そして埋まると、10秒で 504 PGRST003 を返します。 なぜ気にするか： supabase-jsやfetchしか使っていなくても、57本のうち11本はここで消えています。 slow(2.5)（2.5秒かかる関数）を、Data API経由で50本同時に呼びました[ラボ]。 200 x 40 待ち時間 2.5〜10.1 秒 504 PGRST003 x 10 10 秒ちょうど → 10本ぶんが順に処理され、あふれた10本は10秒で諦めました。 バックエンドの authenticator は11本で、内訳はプール10本と LISTEN "pgrst" の1本です（pg_stat_activity の query で確認）。 また、anon ロールには statement_timeout = 3s があるため、4秒の関数を呼ぶと HTTP 500 と、PostgreSQLのエラーコード 57014（クエリが時間切れで打ち切られた、という意味）が返ります。 注意 公開された遅い関数は、外部の人にData APIのプールを握らせます。今回の slow() は検証のため anon から呼べるようにしていますが、本物のプロジェクトでこういう関数を公開しないでください。 あなたがやること： 式①に「Data API 11本」を固定で入れる。公開している関数に重いものがないか確認する。 10. トランザクションモードで壊れるものは何か 答え： prepared statement（ライブラリが「このクエリは解析済み」と名前を付けて接続に覚えさせる仕組み。接続が別のクライアントに渡ると、その記憶が食い違って壊れます）と、パイプライン（1本の接続に複数のクエリを重ねて送ること）です。postgres.jsのハングは後者が原因で、prepare: false だけでは直りませんでした。 なぜ気にするか： 「動かない」ではなく「固まって返ってこない」ので、タイムアウトを設定していないと気づけません。 [ドキュメント]（Connecting to Postgres）は、いまははっきり書いています。 > クエリのパイプラインはサポートされません。トランザクションモードは、1つの応答が終わったのを見た時点で接続をプールに返すので、クライアントがその接続にすでに次のクエリを積んでいても返してしまいます。 > > 注意: postgres.js は既定でクエリをパイプライン化するので、この組み合わせはクエリを固まらせたり、食い違った行を返したりすることがあります。 私が見たのは、この「固まる」ほうです。原因を1つずつ切り分けました。 | 設定 | [ラボ] トランザクション | [ホスト版] プール3 | 直接 | |---|---|---|---| | 既定 | ハング | ハング | OK | | prepare: false だけ | ハング | ハング | | | max_pipeline: 1 だけ | OK（1.0秒） | OK | | | 両方 | OK | OK | | → 効いたのは max_pipeline: 1 のほうで、prepare: false ではありません。 定番の対処として知られているのは prepare: false ですが、それだけでは直りませんでした。 「エラーが出ないのは、postgres.jsが黙ってやり直しているからでは」という疑いも確かめました（ここは細かい確認なので、飛ばして構いません）。クライアントがサーバーに送る「Parse」というメッセージの数を数えたところ、max_pipeline: 1 だけのときは接続の数（10）しか送られていませんでした。やり直しがあれば、もっと増えるはずです。データベースとSupavisorのログにも 26000 の行はありませんでした。→ やり直しで隠しているのではなく、そもそもエラーが起きていません（なぜ起きないのかは分かりません）。 ドキュメントが警告するもう1つ、食い違った行も探しました。1クエリごとに違う目印を送り、返りを全部照合します。 | 設定（プーラー、トランザクション）[ラボ] | 300クエリ / 10接続 | 食い違った行 | |---|---|---| | 既定 | ハング（この回は69件で停止。位置は毎回変わる） | — | | prepare: false だけ | ハング（この回は144件） | — | | max_pipeline: 1 だけ | OK（58ミリ秒） | 0件 | | prepare: false かつ max_pipeline: 1 | OK（38ミリ秒） | 0件 | | （対照）直接つなぐ、既定 | OK（15ミリ秒） | 0件 | → 上の表（300クエリ×10接続）に加えて、1000クエリ×20接続も3回流しましたが、食い違った行は1件も出ませんでした。 私の環境では、食い違う前に固まります。ただし「出なかった」は「起きない」ではないので、ドキュメントの警告のほうを信じてください。 max_pipeline: 1 をすすめる以上、トランザクションを壊さないかも確かめる必要がありました。[ドキュメント]の Postgres.js のページ には「max_pipeline: 0 は sql.begin() のトランザクションを壊す」とありますが、私がすすめているのは 1 です。 | 設定（プーラー、トランザクションモード）[ラボ] | 結果 | 値の食い違い | トランザクションの分断 | |---|---|---|---| | 既定 | OK（16ミリ秒） | 0 | 0 | | max_pipeline: 1 | OK（18ミリ秒） | 0 | 0 | | prepare: false かつ max_pipeline: 1 | OK（17ミリ秒） | 0 | 0 | | max_pipeline: 0 | エラー 42P05 prepared statement "..." already exists | — | — | | prepare: false かつ max_pipeline: 0 | OK、ただし2029ミリ秒 | 0 | 0 | → max_pipeline: 1 は sql.begin() を壊しませんでした（8〜30トランザクションで3回繰り返し）。一方 max_pipeline: 0 はパイプラインを完全に止めるため、クエリが1本ずつ順番待ちになり、100倍以上遅くなりました（max_pipeline: 1 の18ミリ秒に対して、2029ミリ秒）。 prepared statementが原因のものも、ちゃんとありました[ラボ]。 - Prisma 6: URLに ?pgbouncer=true がないと、30クエリのうち22本が prepared statement "sN" does not exist で失敗（付けると0本）。紛らわしい名前ですが、共有プーラー（Supavisor）のトランザクションモードでも、このオプションが必要です。 - psycopg 3: 同じクエリを5回以上流すと自動でprepareされて壊れます。prepare_threshold=None で0本。1回ずつの試しでは気づけません。 - Prisma 7 + pgアダプタ、node-postgres: 壊れませんでした。 注意 同じ検査をPgBouncer 1.26.1（同じDBの前に置いたもの）に流すと、postgres.jsの既定もpsycopgもPrisma 6も、すべてエラーなしでした。ただしこれはコンテナの既定値であり、ホスト版の専用プーラーと同じ設定とは限りません。 あなたがやること： postgres.jsなら、次のように書いたうえで、自分のトランザクションで検証してから使う（ドキュメントに載っている対処ではありません）。 const sql = postgres(process.env.DATABASE_URL, { max: 10, max_pipeline: 1, // トランザクションモード（ポート6543）で固まるのを防ぐ }) Prisma 6なら接続URLに ?pgbouncer=true、psycopg 3なら prepare_threshold=None を付けてください。 11. 接続は、いつ消えるのか 答え： 実測では約2分です。ただし[ドキュメント]（Supavisor FAQ）は最大5分と書いているので、見積もりは5分でしてください。 なぜ気にするか： 「もう止めたのに枠が空かない」という状態が数分続き、復旧の判断を誤らせるからです。 [ドキュメント]（SupavisorのFAQ）には3つの主張があります。3つとも測りました。 | [ドキュメント]の主張 | 私が測ったもの | |---|---| | トランザクションモードは、5分使われなければ閉じる | [ラボ] 約2分（105秒では残り、120秒で消えた。2回）。[ホスト版] 106秒では6本のまま、122秒で0本。どちらも約2分で、5分ではありません | | クライアントがいる間は、最低1本は維持される | [ホスト版] クライアント1本を放置 → バックエンドは1本のまま137秒後も維持。確かに維持されていました | | セッションモードは、すぐ閉じる | [ホスト版] 1本つないで切断 → バックエンドは3分以上残り、あとから来たクライアントに再利用されました。消えたのはアイドル4〜5分ごろ。「すぐ」ではありません | → 3つのうち2つは、実測と違いました。 それでも見積もりには大きいほう（5分）を使ってください。私が測ったのはプロジェクト1つ・数回ぶんだからです。 !ホスト版のダッシュボードに出る接続数。テスト直後で、実行中のクエリは0なのに41本が残っている（2026-11-02） 上の画面は、テストを止めた直後のものです。誰も使っていないのに41本が残っているのが、この「消えるまでの時間」です。 !クライアントを閉じてから約2分で、プーラーの接続が消える（ローカル） 関連して、「エラーが出ないまま遅くなる」ことも確かめました。1ロール・トランザクションモード・クエリ100ミリ秒で、クライアント数だけを変えます[ラボ]。 !クライアントを増やしても、待ち時間が増えるだけ（100ミリ秒のクエリ） | クライアント | 毎秒のクエリ | p50 | p95 | |---|---|---|---| | 5 | 47 | 104 ms | 112 ms | | 16 | 152 | 105 ms | 108 ms | | 40 | 154 | 218 ms | 312 ms | | 100 | 153 | 620 ms | 724 ms | → 16本を超えると毎秒約150回で頭打ちになり、増えるのは待ち時間だけ。エラーは1件も出ません。 だからp95を見ないと気づけません。 注意 [ラボ] データベース側がアイドルの接続を切った（pg_terminate_backend）とき、node-postgresの Pool は error ハンドラなしだとプロセスごと落ちました。pool.on('error', ...) を付けておけば、次のクエリから復帰します。SQLAlchemyは最初のクエリが失敗したので、create_engine(..., pool_pre_ping=True) を付けてください。 あなたがやること： 監視にp95を入れる。短いテストを連続で回すときは、前のテストの接続が残っている前提で数える。 12. 1つのロールに、みんなを巻き込ませないために 答え： ロールごとの connection limit が効きます。ただしプールサイズ + 1以上にしてください。statement_timeout だけでは守れません。 なぜ気にするか： 4章のとおり、1つのロールの使いすぎがAuthやほかのロールまで巻き込むからです。 > どのロールに付けるのか。 下の r1 はラボで作ったロールです。あなたのプロジェクトでは、自分で作ったロール（たとえば前章の batch_user のようなバッチ用）に付けてください。authenticator には付けないでください（Data APIが止まります）。postgres に付けるのも避けたほうが安全です（ダッシュボードや管理作業が入れなくなります）。 ロールごとの接続上限: alter role r1 connection limit 10 とすると、r1は10本で止まり、20クエリのうち10本が too many connections for role "r1" で即座に失敗しました。ほかのロール（r2）は影響なしです。ただし上限の値には注意が要ります[ラボ、プール15、40クライアント×5秒クエリ]。 | connection limit | r1のバックエンド | 失敗したクエリ | |---|---|---| | 15（プールサイズと同じ） | 15 | 25 / 40（すぐに失敗） | | 16（プールサイズ + 1） | 16 | 0（残りは待つ） | → ぴったりにすると16本目が拒否され、待てるはずのクライアントまでエラーになります。 2章の「+1」がここで効いてきます。 ロールごとのタイムアウト: alter role r1 set statement_timeout = '2s' で4秒のクエリは2.0秒で止まりました。ただし、どのロールも自分の statement_timeout を変えられます。 クライアントが SET statement_timeout = 0 を実行でき、しかもトランザクションモードでは次のクライアントにも0が残ります（6章）。つまり権限では防げません。 そのため、セッションの外に後ろ盾が要ります。pg_cron で5秒ごとに、長すぎるクエリを打ち切るジョブを動かしました。 -- 拡張機能 pg_cron を有効にしてから select cron.schedule('cancel-long-queries', '5 seconds', $$ select pg_cancel_backend(pid) from pg_stat_activity where usename = 'batch_user' -- 対象は自分で作ったロールだけに絞る and state = 'active' and now() - query_start > interval '6 seconds' $$); これを動かしたところ、SET statement_timeout = 0 をしたクライアントの30秒クエリが10〜11秒（6秒 + ジョブ間隔）で止まりました。 監視用のロール: 満杯のときに監視ロールがつながらないと、原因が見えません。PostgreSQL 17では reserved_connections を設定しロールに pg_use_reserved_connections を渡すと、満杯でもつながりました[ラボ]。reserved_connections を使うなら、式①の上限からその数を引いてください。 注意 reserved_connections を[ホスト版]で変更できるかは確かめていません（Nanoでは値は0でした）。変えられない可能性があるので、この手は当てにせず、満杯のときはダッシュボードから入る前提で考えておくほうが安全です。 あなたがやること： プーラーを使うロールの connection limit を「プールサイズ + 1」以上に設定する。長いクエリを止める定期ジョブを用意する。 13. 費用 - 今回の実験は約0.02ドルでした。ほとんどが自分のPCのDocker（0ドル）と無料プロジェクトでの短い確認で、使い捨てのProプロジェクト（Micro）を約1.5時間だけ動かし、終わったあと削除しました。 - [ドキュメント]（Compute and disk、2026-11-04）: Nanoは無料。有料プランのいちばん小さいコンピュートはMicroで月約10ドル、上限はNanoと同じ（直接60、クライアント200、プールサイズ15）。この「Nanoと同じ」はProプロジェクトで実際に読んで確かめました。 Smallは約15ドル（90／400）、Mediumは約60ドル（120／600）、XLは約210ドル（240／1000）。 - Largeはページによって数字が違い、Compute and diskでは約110ドル、Manage your usage / Computeでは約111ドルです。どちらも時間単価は0.1517ドルなので、月換算のしかたの違いです（0.1517 × 730 = 110.74）。 - Proプランは月25ドルで、コンピュートのクレジット10ドル分が含まれMicro 1プロジェクトぶんをまかないます。プランを上げるだけでは接続の余裕は増えません。 増えるのはコンピュートのサイズを上げたときです。 - コンピュートは時間単位で課金され、上限（Spend Cap）の対象外です[ドキュメント]。つまり、コンピュートサイズを上げたぶんの料金は、Spend Capでは止まりません。 - 専用プーラーにつなぐにはIPv6が必要で、IPv4だけの回線からはIPv4アドオン（月4ドル）が要ります。私は使わなかったので、専用プーラーの実測はありません。 14. 実際の運用にするなら（まだ試していません） - プールサイズは、(ロール数 × モード数 × (プール + 1)) + Data API + Auth + Storage + Realtime + 監視 が、max_connections から予約を引いた数に収まるかで決める。設定場所は Project Settings → Database → Connection pooling です。専用プーラーも同時に使うなら、そのぶんも足す。 実測値は、Data API 11本、Auth 10本（使われたあと。約1分で手放す）、Storage 8本（使われたあと、持ったまま）[ホスト版]。Realtimeは[ラボ]で5〜7本、監視は[ホスト版]で1〜2本でしたが、Realtimeの本数は同時接続数で変わるはずで、ホスト版では測っていません。ここは自分のプロジェクトで数えてください（→ 5章のSQL）。 - アプリのコピー数 × ライブラリのプール を、クライアント上限（ロールごとに200、コンピュートサイズで固定）と比べる。サーバーレスはとくに。ただしロールを足してもバックエンドの枠は増えません。 - 待ち時間の上限（Supavisor 60秒、PostgREST 10秒、anon 3秒、Prisma 6の10秒、ライブラリ30秒、postgres ロールは2分。Prisma 7のpgアダプタとnode-postgresは既定で無制限）を、ひとつの「はしご」として揃える。 - ロールごとの connection limit（プールサイズ + 1以上）、statement_timeout、idle_in_transaction_session_timeout。SET ではなく set_config(..., true)。クライアントに外されない後ろ盾として、長いクエリを止める定期ジョブ。 - postgres.jsを使うなら、max_pipeline: 1 を自分のトランザクションで確かめる。 - 監視ロールが満杯のときにもログインできるかを、使い捨ての環境で確かめる。 - [ホスト版]でのさらなる確認（クライアント接続数のグラフ、PostgRESTのプール設定、+1が全リージョンで同じか、専用プーラーのバックエンド本数、満杯のときのAuthの粘り）。 15. 検証メモ：つまずきと、考えを変えたところ 結果だけ読みたい方は、ここは飛ばしてください。再現する方のための記録です。 ラボ作りでのつまずき 1. max_connections は [db] ではなく [db.settings] に書きます。最初に [db] へ書いても効かず、alter system set で設定したところ、その値が postgresql.auto.conf に残って後から [db.settings] を効かなくしました。alter system reset max_connections と再起動で解決します（pg_settings の source で確認できます）。 2. ラボを90本にしたのは、「空き」をホスト版のNano（60本）に合わせるためです。ローカルのプーラーは管理用に29本（supavisor_meta 27本 + クラスタ用2本）をデータベース内に開きますが、ホスト版ではその分が外にあります。数字が合わないと思ったら、これでした（application_name を見るまで気づきませんでした）。 3. 満杯のとき、数える側の接続まで拒否されました。数える専用に、予約枠のある supabase_admin を使います。 4. シェルの引数の渡し方で、4種類のテストが全部同じ条件で走っていました（zshは引用符なしの変数を単語に分けません）。 5. バッチで続けて走らせると、前のテストの接続が残って数が膨らみます（Prisma 7が10本のはずが26本に見えた）。テストごとにプーラーを再起動して測り直しました。 考えを変えたところ 6. 最初に書いた式①は、実験データと合いませんでした。ラボの満杯は「57／60」で、残り3本は管理者用の予約です。式を max_connections ではなく「予約を引いた数」に直し、トランザクションモードの「+1」も足しました。 7. 「満杯ならData APIは503」と思い込んでいましたが、満杯でも200のことがあります。分かれ目は、持っている接続で足りるかどうかでした。 8. 「Authが先に止まる」も同じ種類の思い込みでした。Authが先だったのは、そのときAuthが接続を持っていなかったからです。 9. 「何もしていないときに0本だから、Authは接続を持たない」と書きかけました。Proプロジェクトで負荷をかけたら10本持っていました。「測っていない」と「0である」は別物です。 10. ドキュメントは2026年10月末に書き換わりました。以前は「プールサイズはポート5432と6543で共有される」という記述がありましたが、現在その文はなく、「ロールごと」に変わっています。古い記事を読むときは日付を見てください。 11. 状態漏れのテストで、set_config(..., true) の確認が前の実験で漏れた値に引きずられ、漏れたように見えました。キー名と順番を直しました。 12. 「食い違った行」を探す最初のテストで一時テーブルを使い、「食い違い」が3件出て一瞬再現したと思いました。違いました。一時テーブルは接続ごとに残るので、同じ接続を使い回した2つ目以降のトランザクションが前の行まで読んでいただけです。私のテストのバグでした。トランザクションモードを試すときは、テスト自身が状態を共有していないかを先に疑ってください。 13. Djangoのプールの実験で connection.close() を忘れ、全滅しました。これも私のバグですが、長く生きるスレッド（バックグラウンド処理など）では本番でも起こります。 まとめ - 危険度順の3つ: ①トランザクションモードでセッション状態が次のクライアントに残り、行と権限が漏れる。②接続は掛け算で増え、有料プランにしても増えない。③満杯になると「新しい接続が必要なもの」から止まる。 - 接続の予算は3つの式: ①バックエンドの合計 ≤ max_connections − 予約、②クライアントの合計 ≤ プーラーの上限、③同時に使う数 = 毎秒のクエリ × 1クエリの秒数。 - プールは「ロール × データベース × モード」ごと。トランザクションモードは「+1」。 - クライアント上限200もロールごと（ソース上の単位はプール＝ロール × モード）。ただしロールを足してもバックエンドの枠は増えない（300クライアントが握っていたバックエンドは2本）。 - 式①にはAuth、Storage、Realtime、監視も入れる。Authは使われたあと10本（約1分で手放す）、Storageは8本（14分後も保持）。 - 待ち時間の上限は、プーラー60秒、PostgREST 10秒、postgres ロール2分。エラーが出ないまま遅くなるのでp95を見る。Prisma 7のpgアダプタには既定の上限がない。 - postgres.jsのハングの原因はパイプライン。max_pipeline: 1 で直り、sql.begin() も壊しませんでした。 - 接続が消えるまでは実測で約2分だが、見積もりは[ドキュメント]（Supavisor FAQ）の5分で。 - connection limit は「プールサイズ + 1」以上に。statement_timeout はクライアントが外せるので、セッションの外に後ろ盾を。 - ライブラリの既定値はバージョンで変わる。実際に動かして数える。 参考にした公式ドキュメント（2026-11-04時点） 記事中で [ドキュメント] と書いたものの出どころです。内容は変わるので、読むときは日付を確かめてください。 - Connection management — プールサイズはロールごと、40%／80%の目安 - Connecting to Postgres — トランザクションモードの制限、パイプライン、セッション状態 - Pooling and limits — クライアント接続とバックエンド接続の上限、合計に含めるサービス - Supavisor FAQ — プールの単位、接続が消えるまでの時間、ホットな接続 - Postgres.js — max_pipeline と sql.begin() - Timeouts — ロールごとの statement_timeout の既定値 - Compute and disk / Manage your usage: Compute — コンピュートサイズごとの上限と料金 - Cost control（Spend Cap） — コンピュートがSpend Capの対象外であること サンプルコード（ラボのスクリプト、結果の表、この式をそのまま計算できるページ）は、冒頭のリポジトリにあります。 続きの記事では、実際に接続が足りなくなったときに何をするかを、症状の見分け方から順に試しました。

Supabase .NET DevLog #16 Welcome to our weekly log for the Supabase .NET SDK 🎉 As mentioned in the previous post, I focused on the automatic generation of our feature compliance file, which is now done. The SDK provides annotations we place on public members to indicate which feature they relate to. After each push on master, the compliance file is regenerated and ready to be pulled by other systems. An additional step in our quality gate also verifies that every annotated feature exists in our capability matrix. The file is now my "north star", a backlog of its own: every missing feature is an item that I need to implement. FYI the SDK currently sits at roughly 50% parity with our platform. Since I joined Supabase four months ago, I focused on making the SDK robust enough to move fast(er). Now, we're building momentum and starting a new phase: catching up on the feature drift. As usual, stay tuned and happy coding!

10/30~のSupabaseの GRANT 必須化は既存プロジェクトでも要確認! Supabaseから「新しいテーブルが API に自動で公開されなくなります」というお知らせが来ていました。既存のプロジェクトにも、2026年10月30日から適用されるとの事。 supabase.com 告知には「既存のテーブルは影響を受けません」とありますので、うちは関係ないと放置していました。念のため確かめてみました。すると、新しい環境でマイグレーションを流し直すと管理画面もデータの受信もほぼ全滅する状態でした。 同じように読み流している人向けに、確かめ方と直し方をメモしておきます。 何が変わるのか これまでは、public にテーブルを作ると、API 用のロール（anon・authenticated・service_role）に権限が自動で付いていました。RLS のポリシーを書くだけで supabase-js から使えていたのは、このためです。 これからは自動では付きません。テーブルごとに GRANT を書く必要があり、書かないと API から 42501（permission denied）が返ります。 「既存は影響なし」の落とし穴 今あるテーブルの権限は消されません。本番で今動いているものは、そのまま動きます。 困るのは、次の3つです。 1. これから足すテーブル 10月30日以降に足したテーブルは、GRANT を書かないと使えません。ここは告知にも書いてあります。 2. 新しい環境でマイグレーションを最初から流すとき 検証環境を作るときや、本番を作り直すときです。 これまでのマイグレーションは、自動で公開されることに頼っているので、GRANT が1つもありません。そのため新しい環境では、すべてのテーブルが使えなくなります。 3. 関数も使えなくなる 一番気づきにくいのがこれでした。 ログインユーザーだけに呼ばせたい関数を、こう書いてある場合です。 revoke execute on function public.create_api_key(uuid, text) from public, anon; authenticated には何も書いていないのに呼べていたのは、既定の権限で自動で付いていたからです。 ローカルで「自動で公開しない」状態にして流し直すと、誰からも呼べなくなります。うちでは外部からデータを受信する関数もこれに当たり全部止まるところでした。 ローカルで確かめる Supabase CLI の v2.102.0 以降なら、新しい環境と同じ状態を手元で再現できます。 supabase/config.toml に次を書きます。 [api] auto_expose_new_tables = false DB を作り直して、テストを流します。↓これでローカルのテストデータ消したw supabase db reset # ローカルのデータは消えるので注意 supabase test db うちでは、テストがほぼ全部 permission denied で落ちました....しくしく。 直し方 マイグレーションを1つ足して、次の3つを行います。 今あるテーブルに、権限を明示する 一般の実行権限を外した関数に、呼ぶロールを明示する これから作るものに、権限が自動で付かないようにする 1 と 2 は今付いている権限を書き直すだけなので、既存の環境の動きは変わりません。 -- 1. 今あるテーブルに権限を明示する -- 「all tables in schema public」は RLS のないテーブルまで公開するので使わず、名前を並べる grant select, insert, update, delete on table public.profiles, public.todos -- ...今あるテーブルを全部並べる to anon, authenticated, service_role; grant usage, select on all sequences in schema public to anon, authenticated, service_role; -- 2. 一般の実行権限を外した関数に、呼ぶロールを明示する grant execute on function public.create_api_key(uuid, text) to authenticated, service_role; -- 3. これから作るものには、自動で何も付けない -- （告知の手順は select などだけを取り消し、TRUNCATE などが残るため、all にする） alter default privileges for role postgres in schema public revoke all on tables from anon, authenticated, service_role; alter default privileges for role postgres in schema public revoke all on sequences from anon, authenticated, service_role; alter default privileges for role postgres in schema public revoke all on functions from anon, authenticated, service_role; 3 まで入れると、ローカルも CI も新しい環境も同じ状態になります。GRANT を書き忘れると手元で動かなくなるので、本番に出す前に気づけます。 書き忘れをテストで止める pgTAP のテストにも入れておきました。落ちたときは、GRANT を忘れたテーブルや関数の名前が出ます。 select is( (select string_agg(c.relname, ', ') from pg_class c join pg_namespace n on n.oid = c.relnamespace where n.nspname = 'public' and c.relkind = 'r' and not has_table_privilege('authenticated', c.oid, 'select')), null, 'すべてのテーブルに GRANT を書いている'); select is( (select string_agg(p.oid::regprocedure::text, ', ') from pg_proc p join pg_namespace n on n.oid = p.pronamespace where n.nspname = 'public' and p.prorettype <> 'trigger'::regtype and not has_function_privilege('service_role', p.oid, 'execute')), null, 'すべての関数に GRANT を書いている'); AI に頼むなら Claude Code などに任せる時は下記の指示で一通りやってくれます。 Supabase が 2026-10-30 から、新しいテーブルを API に自動で公開しなくなる （supabase#45329 - supabase/config.toml の [api] に auto_expose_new_tables = false を一時的に書き、 ローカルの DB を作り直してテストを流し、何が使えなくなるかを確かめる （db reset はローカルのデータを消すので、実行前に確認して） - 今あるテーブルに、今と同じ API の権限を GRANT で明示するマイグレーションを足す。 all tables in schema public は使わず、テーブル名を並べる - revoke execute ... from public で一般の実行権限を外した関数には、 今それを呼べているロール（authenticated や service_role）への grant execute を明示する - public の既定の権限（テーブル・連番・関数）を revoke all で取り消す - 書き忘れを止めるテストを足す - 最後に auto_expose_new_tables の行を戻し、同じ状態でもテストが通ることを確かめる 大事なのは、最初に「auto_expose_new_tables = false で作り直して確かめる」を頼むことです。これがないと、テーブルに GRANT を足しただけで終わりがちで、関数の問題には気づきません。 直した後も、AI は新しいテーブルを作るときにはGRANT のない昔の書き方をしがちです（テストを書いてうごかしていたら気づいてくれますが）。そこで、CLAUDE.md や AGENTS.md に、決まりとして書いておくと良いでしょう。 - テーブルを作るマイグレーションでは、同じファイルで GRANT を書き、RLS を有効にする （Supabase は新しいテーブルを API に自動で公開しない） - revoke execute ... from public で一般の実行権限を外した関数は、 呼ぶロールに grant execute を書く - grant ... on all tables in schema public は使わない（RLS のないテーブルまで公開するため） まとめ 「既存のテーブルは影響を受けません」が、マイグレーションを流し直す時には修正が必要です。障害で作り直すときに全滅に気づく、という事態は避けたいので一度確かめておくのがおすすめです。

Supabase functions search path with '' vs explicit schema list On October 21, Supabase merged PR #69 into supabase/vault. Two of its functions changed: search_path = '' → search_path = pg_catalog, pg_temp. Link to the github PR vault#69 1.What is SECURITY DEFINER? A function that runs with its owner's rights, not the caller's. On Supabase the owner is usually postgres, which bypasses RLS. It's a hole in the wall you cut on purpose, so it has to stay exactly the size you planned. 2.'' vs explicit An empty search_path does NOT mean "search nothing". Postgres always searches pg_catalog and the caller's own temp schema (pg_temp). If pg_temp isn't listed, it's searched FIRST, even before pg_catalog, for table and type names. 3.What can go wrong with search_path = ''. Anyone with a direct SQL session can create a temp table that shadows a name your function uses: → An unqualified table can return the attacker's fake row → A temp table named jsonb made auth.uid() fail inside the function. Harmless in itself, but it proves the caller’s objects reach your security definer code. The Supabase API can't do this. Direct connections can: BI tools, contractors or AI agents with database access. 4.The safe pattern create function private.can(p_tenant uuid, p_permission text) returns boolean language sql stable security definer set search_path = pg_catalog, pg_temp as $$ select exists ( select 1 from private.memberships m -- always schema-qualified join private.role_permissions rp on rp.role_id = m.role_id where m.user_id = (select auth.uid()) and m.tenant_id = p_tenant and rp.permission = p_permission ) $$; Both layers matter: the path protects built-in types, and qualified names protect your own tables. Don’t take my word for it: run bellow lines in the SQL editor and compare the order yourself. The temp schema only appears after you create a temp table. --temp FIRST create temp table x (id int); set search_path = ''; select current_schemas(true); -- {pg_temp_N, pg_catalog} --temp LAST set search_path = pg_catalog,pg_temp; select current_schemas(true); -- {pg_catalog, pg_temp_N}

MCP クライアントが OAuth でMCP サーバにつながる仕組み Claude アプリの設定で MCP サーバーの URL を貼ると、ブラウザでログイン画面が開き、「許可する」を押すだけでつながります。API キーを発行した覚えも、アプリを登録した覚えもありません。最近よく見るこの認証です。 でも、考えてみると不思議です。Claude アプリに入力したのは MCP サーバーの URL だけなのに、ログイン画面の場所はどうやって分かったのでしょうか。逆に、接続先のサービスは Claude というアプリのことをどうやって知ったのでしょう。同意画面に出ている「Claude」は、本当に Claude 自分の使っている Claude アプリなのでしょうか。 MCP の OAuth には、まず次の 2つの「相手を知る」仕組みがあります。 認可サーバーを見つける：MCP クライアントは、どこにログインしに行けばいいのか？ → OAuth discovery MCP クライアントを識別する：認可サーバーは、接続してきたアプリが誰なのか？ → 事前登録・DCR・CIMD この順番で見ると、MCP サーバーの URL だけで接続できる理由が分かります。最後に Better Auth、Neon、Supabase の対応状況も比較します。 まずは登場人物 MCP クライアント：Claude や ChatGPT、Cursor など、MCP サーバーにつなぐ AI アプリ。OAuth では「クライアント」 MCP サーバー：ツールやデータを提供する側。OAuth ではアクセスを保護される「リソースサーバー」 認可サーバー：ユーザーのログインと同意を受け付け、MCP サーバー用のアクセストークン（通行証）を発行する側 MCP サーバーと認可サーバーは同じサービス内にあっても、別のドメインや別のサービスにあっても構いません。だから、MCP サーバーの URL を知っているだけでは、認可サーバーの場所が分からない場合があります。 1. 認可サーバーの場所をどう伝えるか：OAuth discovery discovery がなかったらどうなる？ 従来の OAuth 連携では、アプリの開発者が接続先のサービスをあらかじめ知っていて、認可エンドポイントやトークンエンドポイントを設定しておくのが一般的でした。 例えば、次の情報を手動で用意します。 MCP サーバー: mcp.example.com 認可エンドポイント: auth.example.com トークンエンドポイント: auth.example.com これは接続先が決まっているアプリなら問題ありません。しかし MCP では、MCP クライアント に新しい MCP サーバーの URL を貼るたびに、そのサーバーがどの認可サーバーを使うか分かるとは限りません。認可先が別のドメインなら、MCP サーバーの URL から推測することもできません。 実は 2025年3月版の MCP 仕様には、メタデータで発見できない場合、MCP サーバーと同じオリジンの /authorize、/token、/register を試すフォールバックがありました。例えば mcp.example.com なら mcp.example.com を試す方式です。 ただし、このフォールバックは認可サーバーが別の場所にあれば使えません。 そこで 2025年6月版以降の MCP 仕様では、MCP サーバーが認可サーバーの場所を公開する仕組みを使います。これが OAuth discovery です。 discovery がある場合：2段階で見つける ポイントは、見つけるメタデータが 2種類あることです。 誰が公開する？ 仕様 クライアントに教えること MCP サーバー RFC 9728：Protected Resource Metadata どの認可サーバーを使うか 認可サーバー RFC 8414：Authorization Server Metadata（または OIDC Discovery） ログイン先・トークン発行先・対応する登録方式 例えば mcp.example.com にアクセスしてトークンを持っていないと、MCP サーバーは次のように応答します。 HTTP/1.1 401 Unauthorized WWW-Authenticate: Bearer resource_metadata="mcp.example.com" クライアントがその URL にアクセスすると、次のような Protected Resource Metadata を受け取ります。 { "resource": "mcp.example.com", "authorization_servers": ["auth.example.com"] } これで「認可サーバーは auth.example.com にある」と分かります。続いて認可サーバーの /.well-known/oauth-authorization-server などを取得すると、例えば次の情報が分かります。 { "issuer": "auth.example.com", "authorization_endpoint": "auth.example.com", "token_endpoint": "auth.example.com", "client_id_metadata_document_supported": true } authorization_endpoint がブラウザでログイン・同意を受ける先、token_endpoint が認可コードをトークンに交換する先です。最後の client_id_metadata_document_supported は、後半で説明する CIMD に対応していることを示します。 図の alt の部分がポイントです。WWW-Authenticate にメタデータの URL がなくても、discovery がないとは限りません。ヘッダー経由か well-known URL 経由かの違いで、どちらも RFC 9728 の discovery です。MCP サーバー側はどちらか一方を実装すればよく、ヘッダーで場所を伝えるなら、メタデータの URL は標準の well-known パスでなくても構いません。 一方、RFC 9728 のメタデータ自体がない場合は別です。手動で認可先を設定する独自の接続方法は考えられますが、MCP の OAuth 仕様には適合しません。RFC 9728 の実装は 2025年6月版から必須で、2026年7月版（現行）でも変わっていません。 ここまでで「どこへログインしに行くか」が分かりました。しかし、認可サーバーにはもう1つ知りたいことがあります。「あなたはどのアプリですか？」です。 2. 接続するアプリをどう識別するか：事前登録・DCR・CIMD OAuth では、アプリを識別する ID を client_id と呼びます。認可サーバーは、ログインの要求に付いてくる client_id を見て、アプリの情報やログイン後の戻り先を確認します。 この client_id を使えるようにする仕組みが3つあります。 方式 client_id を用意するのは たとえるなら 事前登録 管理者が事前に登録し、認可サーバーが発行 受付の名簿に前もって名前を載せてもらう DCR（Dynamic Client Registration） アプリが要求し、認可サーバーが発行 受付で自分で用紙を書き、番号札をもらう CIMD（Client ID Metadata Document） アプリ自身が公開する HTTPS URL 公式サイト上の名刺を渡し、受付が見に行く 事前登録：人が登録してから使う 従来の OAuth では、管理者が認可サーバーの管理画面でアプリを登録し、発行された client_id をアプリの設定に書き込みます。 利点：登録済みの相手を管理しやすい。既知のアプリ同士ならシンプル 課題：アプリと認可サーバーの組み合わせごとに事前の登録作業が必要 Web アプリが数個なら手作業で回ります。しかし MCP では、たくさんの AI アプリがたくさんのサーバーにつながるので、登録作業が掛け算で増えます。 DCR：アプリが自分で登録する DCR は、アプリが認可サーバーの登録エンドポイントに「私はこういう名前で、ログイン後はここに戻してほしい」と送り、その場で client_id を受け取る方式です。 解決したこと：人手による事前登録なしで「MCP サーバーの URL を貼るだけ」の体験を実現しやすくなった 課題： アプリ名は原則として自己申告で、追加の審査がなければ誰でも「Claude」を名乗れる 再登録のたびに client_id が増える運用では、同じアプリの登録が溜まる client_id は認可サーバーごとに別物になる CIMD：自己紹介ファイルの URL を ID にする CIMD は、アプリが自分の HTTPS サイトに自己紹介の JSON を置き、その URL 自体を client_id として使う方式です。認可サーバーがその URL を取りに行って内容を確かめるため、接続のたびに登録 API から ID を発行してもらう必要がありません。 Claude も、実際に自己紹介ファイルを公開しています。 Claude（claude.ai、デスクトップ版などの MCP 接続向け）：claude.ai 以下は主要な項目の抜粋です。 { "client_id": "claude.ai", "client_name": "Claude", "client_uri": "claude.ai", "redirect_uris": ["claude.ai"], "token_endpoint_auth_method": "none" } client_id が自分自身の URL、client_name が表示名、redirect_uris がログイン後の戻り先です。token_endpoint_auth_method: "none" は、このクライアントがトークンエンドポイントでクライアントシークレットによる認証をしないことを示します。Claude Code は 別の自己紹介ファイル を使い、戻り先を localhost にして利用者の PC に戻す構成です。 解決したこと： 身元をアプリが管理する HTTPS ドメインと結びつけられる。誰でも登録時に「Claude」と書ける DCR より、表示名の出所を確認しやすい 登録 API を呼ばずに、同じ client_id を複数の対応する認可サーバーで再利用できる 接続のたびに新しい ID を発行する必要がない 注意点： URL の取得先を悪用した SSRF（内部ネットワークへの不正アクセス）への対策が必要 認可サーバーが取得したメタデータをキャッシュ・保存する場合はある。「何も保存しない」という意味ではない ドメインを確認しても、動いているプログラムそのものの身元まで完全に証明できるわけではない。特にローカルアプリの戻り先には追加の注意が必要 MCP の推奨は DCR から CIMD へ 時期 MCP 仕様での扱い 2025年3月 認可の仕組みが導入され、DCR を推奨 2025年6月 認可サーバーの発見に RFC 9728 が必須になり、旧フォールバックは廃止。登録方式は引き続き DCR を推奨 2025年11月 CIMD を推奨し、DCR は任意対応に 2026年7月（現行） DCR を非推奨（deprecated）と明記。互換性のため残る 2026-07-28 版の MCP 仕様は、次の順番で選ぶよう勧めています。 すでに登録情報を持っていれば、事前登録を使う 認可サーバーが client_id_metadata_document_supported: true を公開していれば、CIMD を使う それが使えず、registration_endpoint があれば、DCR を使う どれも使えなければ、ユーザーにクライアント情報の入力を求める ここで client_id_metadata_document_supported や registration_endpoint を知る手段が、先ほどの 認可サーバーの discovery（RFC 8414） です。つまり discovery と CIMD は別の仕組みですが、接続フローの中ではつながっています。 3. URL を貼ってから「許可する」まで 2つの仕組みを合わせると、最初の疑問に答えられます。 ユーザーが Claude (MCP クライアント) に MCP サーバーの URL を設定する Claude が MCP サーバーの Protected Resource Metadata（RFC 9728） から認可サーバーを知る Claude が認可サーバーの メタデータ（RFC 8414 など） からログイン先と利用可能な登録方式を知る Claude が client_id を用意する（事前登録・CIMD・DCR のいずれか） ブラウザにログイン・同意画面が開く ユーザーが「許可する」を押すと、Claude が認可コードを受け取り、PKCE を使ってトークンに交換する。このとき resource パラメータで「どの MCP サーバー用のトークンか」も指定する Claude が アクセストークン を付けて MCP サーバーのツールを呼ぶ 利用者には「URL を貼る → ログインする → 許可する」だけに見えますが、裏側では 認可先の発見 と クライアントの識別 が別々に進んでいます。 観点 OAuth discovery 事前登録・DCR・CIMD 解決する疑問 どこでログインする？ どのアプリが接続する？ 主に情報を示す側 MCP サーバーと認可サーバー MCP クライアントと認可サーバー 重要なメタデータ authorization_servers、authorization_endpoint など client_id、redirect_uris など 2026年7月版 MCP での扱い RFC 9728 による discovery が必須（2025年6月版から） CIMD を推奨、DCR は非推奨 4. Better Auth・Neon・Supabase の対応状況 Better Auth：discovery と CIMD の両方に対応 Better Auth の MCP プラグインは、OAuth の認可サーバー情報と RFC 9728 の Protected Resource Metadata を公開できます。さらに CIMD プラグインを組み合わせることで、URL 形式の client_id を受け入れられます。CIMD は 1.7（2026年8月）で追加された機能で、プラグインを入れたときだけ discovery に client_id_metadata_document_supported が載ります。 CIMD プラグイン自体は IETF draft の新しい版（draft-02）に準拠しており、MCP 2026年7月版が参照する draft-00 の要件（client_name と redirect_uris の必須化）は metadataProfile: "mcp-2026-07-28" を指定して上乗せします。DCR は明示的に有効化しない限り無効です。 Neon：公式 MCP サーバーは DCR のまま、Neon Auth は CIMD が既定 Neon の公式 MCP サーバー（mcp.neon.tech OAuth discovery に対応していますが、クライアント登録は DCR です。CIMD を受け入れる PR #380 が2026年10月に出されていますが、本記事執筆時点では未マージです。 一方、Neon Auth（Managed Better Auth）の OAuth provider プラグインで MCP サーバーの URL を設定すると、CIMD が既定で有効になり、DCR は「legacy」扱いで既定オフになります。2026年10月にこの既定が切り替わったため、それ以前に設定したブランチで DCR に依存していた場合は、明示的にオンにし直す必要があります。管理用の API と後述の SDK はベータ扱いですが、プラグイン自体はすべての Managed Better Auth プロジェクトで使えます。Neon 公式 MCP サーバーの仕組みと、Neon Auth を使った自作 MCP サーバーの実装は分けて考える必要があります。 2026年10月には、Neon Auth を使うアプリや MCP サーバー向けの @neon/oauth（ベータ） も加わりました。MCP サーバー用の RFC 9728 メタデータ公開とトークン検証に加えて、OAuth クライアントが CIMD で名乗るための自己紹介ファイルの生成にも対応しています。 Supabase：discovery を簡単に実装できるが、クライアント登録は DCR Supabase は2026年10月22日に Give your Supabase app its own MCP server を公開しました。新しい MCP Server block を使うと、Edge Functions に MCP サーバーを追加できます。 @supabase/server の withOAuthProtectedResource() が OAuth discovery（RFC 9728） を担当し、認可サーバーの場所を示すメタデータや、未認証時の 401 / WWW-Authenticate 応答を提供します。このメタデータは標準の well-known パスではなく関数配下の URL で配信され、場所は WWW-Authenticate ヘッダーで伝えます。前半で触れた「ヘッダー経由の discovery」の実例です。withSupabase({ auth: 'user' }) はトークンを検証し、ツールをログインユーザーの権限（RLS）で動かします。OAuth Consent block も用意されています。 ただし、discovery に対応したことは CIMD に対応したことを意味しません。外部 MCP クライアント向けの MCP Server block のガイドでは、今も DCR を有効にするよう案内されています。 [auth.oauth_server] enabled = true authorization_url_path = "/oauth/consent" allow_dynamic_registration = true CIMD 対応を求める Issue #2850 は2026年10月23日時点で未解決です。Claude のように CIMD を優先するクライアントも、Supabase Auth を認可サーバーとする接続では DCR に切り替えることになります。 今回の Supabase の発表は、MCP サーバー側の認証と discovery の実装を楽にしたという進歩です。一方、接続してくるアプリの識別を DCR から CIMD に移す課題は残っています。 3つを並べると discovery（RFC 9728） CIMD DCR Better Auth 対応 プラグインで対応 明示的に有効化 Neon Auth 対応 既定で有効 legacy、既定オフ Supabase Auth 対応 未対応 有効化を案内 まとめ MCP サーバーの URL を貼るだけでつながる体験は、2つの問いを順番に解決することで成り立っています。 認可サーバーはどこ？ → OAuth discovery（RFC 9728 と RFC 8414 / OIDC Discovery） 接続してきたアプリは誰？ → 事前登録・DCR・CIMD OAuth discovery がなければ、認可先を人が設定したり固定パスから推測したりする必要がありました。MCP の OAuth 仕様は 2025年6月版からその発見方法を標準化しています。そして、認可先が分かった後のクライアント識別も、自己申告の DCR から、HTTPS ドメインに結びつく CIMD へ移りつつあります。Better Auth と Neon Auth はすでに CIMD を推奨または既定にし、Supabase は DCR のままという違いが、その移行の途中経過を表しています。 次に同意画面で「Claude」と表示されたら、どこにログインするのか、そしてその「Claude」という名前をどう確かめたのか。この2つを思い出すと、OAuth の仕組みが少し違って見えるはずです。 参考 MCP 仕様 2026-07-28：Authorization MCP 仕様 2026-07-28：Authorization Server Discovery MCP 仕様 2026-07-28：Client Registration MCP 仕様 2025-11-25：Authorization MCP 仕様 2025-06-18：Authorization（RFC 9728 必須化） MCP 仕様 2025-03-26：Authorization（旧フォールバック） IETF draft：OAuth Client ID Metadata Document Better Auth：MCP Better Auth：CIMD Neon：MCP Server Neon：mcp-server-neon PR #380（CIMD 対応提案） Neon Auth：OAuth Provider プラグイン Neon：@neon/oauth PR #869 Supabase：Give your Supabase app its own MCP server Supabase Library：MCP Server block Supabase Auth：CIMD 対応 Issue #2850

supabase — open-source Postgres backend with auth and realtime Open source Firebase alternative built on Postgres with auth, storage, and realtime APIs. Repository: supabase/supabase What you get: • Provides a hosted Postgres database for web, mobile, and AI apps. • Auto-generates REST and GraphQL APIs directly from your Postgres database. • Supports realtime database change subscriptions over WebSockets. Requirements: • No install needed for the hosted platform; just sign up. Independent summary of a public open-source project. Neural Nexus is not affiliated with, endorsed by, or sponsored by the project authors or GitHub. The voiceover is AI-generated and checked against the public README. The repository is the source of truth. #AI #supabase #opensource #postgres #database [ar] Supabase — واجهة خلفية مفتوحة المصدر لـ Postgres مع ميزات المصادقة والبيانات الفورية بديل مفتوح المصدر لـ Firebase مبني على Postgres، مع ميزات المصادقة والتخزين وواجهات برمجة التطبيقات (APIs) الفورية. المستودع: supabase/supabase المميزات: • قاعدة بيانات Postgres مستضافة لتطبيقات الويب والهواتف المحمولة والذكاء الاصطناعي. • إنشاء واجهات برمجة تطبيقات REST وGraphQL تلقائيًا من قاعدة بيانات Postgres الخاصة بك. • دعم اشتراكات تغييرات قاعدة البيانات الفورية عبر WebSockets. المتطلبات: • لا يتطلب تثبيتًا للمنصة المستضافة؛ ما عليك سوى التسجيل. ملخص مستقل لمشروع مفتوح المصدر. لا تنتمي Neural Nexus إلى مؤلفي المشروع أو GitHub، ولا تحظى برعايتهم أو دعمهم. تم إنشاء التعليق الصوتي بواسطة الذكاء الاصطناعي وتمت مراجعته مع ملف README العام. المستودع هو المصدر الموثوق. #الذكاء_الاصطناعي #supabase #مفتوح_المصدر #postgres #قاعدة_بيانات [bn] Supabase — অথ এবং রিয়েল-টাইম সুবিধাসহ ওপেন-সোর্স পোস্টগ্রেস ব্যাকএন্ড পোস্টগ্রেস-এর উপর নির্মিত ওপেন সোর্স ফায়ারবেস বিকল্প, যাতে অথেন্টিকেশন, স্টোরেজ এবং রিয়েলটাইম এপিআই রয়েছে। রিপোজিটরি: supabase/supabase আপনি যা পাবেন: • ওয়েব, মোবাইল এবং এআই অ্যাপের জন্য একটি হোস্টেড পোস্টগ্রেস ডেটাবেস প্রদান করে। • আপনার পোস্টগ্রেস ডেটাবেস থেকে সরাসরি স্বয়ংক্রিয়ভাবে REST এবং GraphQL এপিআই তৈরি করে। • ওয়েবসকেটের মাধ্যমে রিয়েলটাইম ডেটাবেস পরিবর্তন সাবস্ক্রিপশন সমর্থন করে। প্রয়োজনীয়তা: • হোস্টেড প্ল্যাটফর্মের জন্য কোনো ইনস্টলের প্রয়োজন নেই; শুধু সাইন আপ করুন। একটি পাবলিক ওপেন-সোর্স প্রকল্পের স্বাধীন সারসংক্ষেপ। নিউরাল নেক্সাস এই প্রকল্পের লেখক বা গিটহাবের সাথে অধিভুক্ত নয়, তাদের দ্বারা অনুমোদিত নয় বা তাদের পৃষ্ঠপোষকতাও পায় না। ভয়েসওভারটি এআই দ্বারা তৈরি এবং পাবলিক README-এর সাথে মিলিয়ে পরীক্ষা করা হয়েছে। রিপোজিটরিটিই তথ্যের মূল উৎস। #AI #supabase #opensource #postgres #database [de-DE] Supabase — Open-Source-Postgres-Backend mit Auth und Realtime Open-Source-Alternative zu Firebase, basierend auf PostgreSQL mit Authentifizierung, Speicherung und Echtzeit-APIs. Repository: supabase/supabase Leistungen: • Gehostete PostgreSQL-Datenbank für Web-, Mobil- und KI-Anwendungen. • Automatische Generierung von REST- und GraphQL-APIs direkt aus Ihrer PostgreSQL-Datenbank. • Unterstützung von Echtzeit-Datenbankänderungsabonnements über WebSockets. Voraussetzungen: • Keine Installation für die gehostete Plattform erforderlich; einfach registrieren. Unabhängige Zusammenfassung eines öffentlichen Open-Source-Projekts. Neural Nexus steht in keiner Verbindung zu den Projektautoren oder GitHub und wird weder von ihnen unterstützt noch gesponsert. Die Sprachausgabe wurde KI-generiert und mit der öffentlichen README-Datei abgeglichen. Das Repository ist die maßgebliche Quelle. #KI #supabase #opensource #postgres #datenbank [es-US] supabase — backend de Postgres de código abierto con autenticación y tiempo real Alternativa de código abierto a Firebase basada en PostgreSQL con autenticación, almacenamiento y API en tiempo real. Repositorio: supabase/supabase Lo que obtienes: • Base de datos PostgreSQL alojada para aplicaciones web, móviles y de IA. • Genera automáticamente API REST y GraphQL directamente desde tu base de datos PostgreSQL. • Admite suscripciones a cambios de base de datos en tiempo real mediante WebSockets. Requisitos: • No se requiere instalación para la plataforma alojada; solo regístrate. Resumen independiente de un proyecto público de código abierto. Neural Nexus no está afiliado, respaldado ni patrocinado por los autores del proyecto ni por GitHub. La narración es generada por IA y verificada con el archivo README público. El repositorio es la fuente de información principal. #IA #supabase #códigoabierto #postgres #basededatos [fr-FR] Supabase — backend Postgres open source avec authentification et temps réel Alternative open source à Firebase, basée sur Postgres et offrant authentification, stockage et API temps réel. Dépôt : supabase/supabase Fonctionnalités : • Base de données Postgres hébergée pour applications web, mobiles et d'IA. • Génération automatique d'API REST et GraphQL directement à partir de votre base de données Postgres. • Prise en charge des abonnements aux modifications de la base de données en temps réel via WebSockets. Prérequis : • Aucune installation requise pour la plateforme hébergée ; il suffit de s'inscrire. Résumé indépendant d'un projet open source public. Neural Nexus n'est ni affilié à, ni approuvé par, ni sponsorisé par les auteurs du projet ou GitHub. La voix off est générée par IA et vérifiée par rapport au fichier README public. Le dépôt fait foi. #IA #supabase #opensource #postgres #base_de_données [hi] Supabase — ऑथेंटिकेशन और रीयल-टाइम फीचर्स के साथ ओपन-सोर्स Postgres बैकएंड Postgres पर आधारित Firebase का ओपन-सोर्स विकल्प, जिसमें प्रमाणीकरण, संग्रहण और रीयलटाइम API शामिल हैं। रिपॉजिटरी: supabase/supabase आपको क्या मिलेगा: • वेब, मोबाइल और AI ऐप्स के लिए होस्टेड Postgres डेटाबेस प्रदान करता है। • आपके Postgres डेटाबेस से सीधे REST और GraphQL API स्वतः उत्पन्न करता है। • WebSockets के माध्यम से रीयलटाइम डेटाबेस परिवर्तन सदस्यता का समर्थन करता है। आवश्यकताएं: • होस्टेड प्लेटफ़ॉर्म के लिए किसी इंस्टॉलेशन की आवश्यकता नहीं है; बस साइन अप करें। एक सार्वजनिक ओपन-सोर्स प्रोजेक्ट का स्वतंत्र सारांश। Neural Nexus का प्रोजेक्ट लेखकों या GitHub से कोई संबंध नहीं है, न ही यह उनके द्वारा समर्थित या प्रायोजित है। वॉइसओवर AI द्वारा जनरेट किया गया है और सार्वजनिक README के ​​अनुसार जांचा गया है। रिपॉजिटरी जानकारी का स्रोत है। #AI #supabase #opensource #postgres #database [id] Supabase — backend Postgres open-source dengan autentikasi dan realtime Alternatif Firebase sumber terbuka yang dibangun di atas Postgres dengan otentikasi, penyimpanan, dan API waktu nyata. Repositori: supabase/supabase Yang Anda dapatkan: • Menyediakan basis data Postgres yang dihosting untuk aplikasi web, seluler, dan AI. • Secara otomatis menghasilkan API REST dan GraphQL langsung dari basis data Postgres Anda. • Mendukung langganan perubahan basis data waktu nyata melalui WebSocket. Persyaratan: • Tidak perlu instalasi untuk platform yang dihosting; cukup mendaftar. Ringkasan independen dari proyek sumber terbuka publik. Neural Nexus tidak berafiliasi dengan, didukung oleh, atau disponsori oleh penulis proyek atau GitHub. Narasi suara dihasilkan oleh AI dan diperiksa terhadap README publik. Repositori adalah sumber kebenaran. #AI #supabase #opensource #postgres #database [it] Supabase — backend Postgres open-source con autenticazione e tempo reale Alternativa open source a Firebase basata su PostgreSQL con autenticazione, storage e API in tempo reale. Repository: supabase/supabase Cosa offre: • Fornisce un database PostgreSQL ospitato per applicazioni web, mobile e di intelligenza artificiale. • Genera automaticamente API REST e GraphQL direttamente dal database PostgreSQL. • Supporta le sottoscrizioni in tempo reale alle modifiche del database tramite WebSockets. Requisiti: • Non è necessaria alcuna installazione per la piattaforma ospitata; basta registrarsi. Riepilogo indipendente di un progetto open source pubblico. Neural Nexus non è affiliato, approvato o sponsorizzato dagli autori del progetto o da GitHub. La voce narrante è generata dall'IA e verificata rispetto al README pubblico. Il repository è la fonte di riferimento. #AI #supabase #opensource #postgres #database [iw] Supabase — backend בקוד פתוח מבוסס Postgres עם אימות וזמן אמת אלטרנטיבה בקוד פתוח ל-Firebase הבנויה על Postgres עם אימות, אחסון וממשקי API בזמן אמת. מאגר: supabase/supabase מה תקבלו: • מספק מסד נתונים Postgres מתארח עבור אפליקציות אינטרנט, מובייל ובינה מלאכותית. • יוצר אוטומטית ממשקי API של REST ו-GraphQL ישירות ממסד הנתונים Postgres שלכם. • תומך במנויים לשינוי מסד נתונים בזמן אמת דרך WebSockets. דרישות: • אין צורך בהתקנה עבור הפלטפורמה המתארחת; פשוט הירשמו. סיכום עצמאי של פרויקט קוד פתוח ציבורי. Neural Nexus אינו מזוהה עם, מאושר על ידי או ממומן על ידי מחברי הפרויקט או GitHub. הקריינות נוצרת על ידי בינה מלאכותית ונבדקת מול קובץ ה-README הציבורי. המאגר הוא מקור האמת. #AI #supabase #opensource #postgres #database [ja] Supabase — 認証とリアルタイム機能を備えたオープンソースのPostgresバックエンド 認証、ストレージ、リアルタイムAPIを備えたPostgresベースのオープンソースFirebase代替サービス。 リポジトリ：supabase/supabase 提供内容： • Web、モバイル、AIアプリ向けのホスト型Postgresデータベースを提供します。 • Postgresデータベースから直接RESTおよびGraphQL APIを自動生成します。 • WebSocket経由のリアルタイムデータベース変更サブスクリプションをサポートします。 必要条件： • ホスト型プラットフォームはインストール不要。サインアップするだけです。 これは公開されているオープンソースプロジェクトの独立した概要です。Neural Nexusは、プロジェクトの作者またはGitHubと提携、承認、またはスポンサー関係にありません。音声はAIによって生成され、公開されているREADMEと照合されています。リポジトリが真の情報源です。 #AI #supabase #opensource #postgres #database [ko] Supabase — 인증 및 실시간 기능을 갖춘 오픈소스 Postgres 백엔드 인증, 스토리지 및 실시간 API를 제공하는 PostgreSQL 기반의 오픈 소스 Firebase 대체 솔루션입니다. 리포지토리: supabase/supabase 주요 기능: • 웹, 모바일 및 AI 앱을 위한 호스팅된 PostgreSQL 데이터베이스를 제공합니다. • PostgreSQL 데이터베이스에서 REST 및 GraphQL API를 자동으로 생성합니다. • WebSocket을 통한 실시간 데이터베이스 변경 구독을 지원합니다. 요구 사항: • 호스팅 플랫폼은 설치가 필요 없으며, 가입만 하면 됩니다. 본 내용은 공개 오픈 소스 프로젝트에 대한 독립적인 요약입니다. Neural Nexus는 프로젝트 작성자 또는 GitHub와 제휴, 보증 또는 후원 관계가 없습니다. 음성 해설은 AI로 생성되었으며 공개 README를 기준으로 검증되었습니다. 저장소가 정확한 정보의 원천입니다. #AI #supabase #opensource #postgres #database [ml] Supabase — ഓതന്റിക്കേഷനും റിയൽ-ടൈം സൗകര്യവുമുള്ള ഓപ്പൺ-സോഴ്സ് പോസ്റ്റ്ഗ്രെസ് ബാക്ക്എൻഡ് ഓത്ത്, സ്റ്റോറേജ്, റിയൽടൈം API-കൾ എന്നിവ ഉപയോഗിച്ച് പോസ്റ്റ്‌ഗ്രെസിൽ നിർമ്മിച്ച ഓപ്പൺ സോഴ്‌സ് ഫയർബേസ് ബദൽ. ശേഖരം: supabase/supabase നിങ്ങൾക്ക് ലഭിക്കുന്നത്: • വെബ്, മൊബൈൽ, AI ആപ്പുകൾക്കായി ഹോസ്റ്റ് ചെയ്‌ത പോസ്റ്റ്‌ഗ്രെസ് ഡാറ്റാബേസ് നൽകുന്നു. • നിങ്ങളുടെ പോസ്റ്റ്‌ഗ്രെസ് ഡാറ്റാബേസിൽ നിന്ന് നേരിട്ട് REST, GraphQL API-കൾ സ്വയമേവ ജനറേറ്റ് ചെയ്യുന്നു. • വെബ്‌സോക്കറ്റുകൾ വഴി റിയൽടൈം ഡാറ്റാബേസ് മാറ്റ സബ്‌സ്‌ക്രിപ്‌ഷനുകളെ പിന്തുണയ്ക്കുന്നു. ആവശ്യകതകൾ: • ഹോസ്റ്റ് ചെയ്‌ത പ്ലാറ്റ്‌ഫോമിന് ഇൻസ്റ്റാളേഷൻ ആവശ്യമില്ല; സൈൻ അപ്പ് ചെയ്‌താൽ മതി. ഒരു പൊതു ഓപ്പൺ സോഴ്‌സ് പ്രോജക്റ്റിന്റെ സ്വതന്ത്ര സംഗ്രഹം. ന്യൂറൽ നെക്‌സസ് പ്രോജക്റ്റ് രചയിതാക്കളുമായോ GitHub-മായോ അഫിലിയേറ്റ് ചെയ്തിട്ടില്ല, അംഗീകരിച്ചിട്ടില്ല, അല്ലെങ്കിൽ സ്പോൺസർ ചെയ്തിട്ടില്ല. വോയ്‌സ്‌ഓവർ AI- സൃഷ്ടിച്ചതും പൊതു README-യ്‌ക്കെതിരെ പരിശോധിച്ചതുമാണ്. സത്യത്തിന്റെ ഉറവിടമാണ് ശേഖരം. #AI #supabase #opensource #postgres #database [nl-NL] supabase — open-source Postgres-backend met authenticatie en realtime Open source Firebase-alternatief gebouwd op PostgreSQL met authenticatie, opslag en realtime API's. Repository: supabase/supabase Wat je krijgt: • Biedt een gehoste PostgreSQL-database voor web-, mobiele en AI-applicaties. • Genereert automatisch REST- en GraphQL-API's rechtstreeks vanuit je PostgreSQL-database. • Ondersteunt realtime abonnementen op databasewijzigingen via WebSockets. Vereisten: • Installatie is niet nodig voor het gehoste platform; meld je gewoon aan. Onafhankelijke samenvatting van een openbaar open-source project. Neural Nexus is niet gelieerd aan, onderschreven door of gesponsord door de projectauteurs of GitHub. De voice-over is door AI gegenereerd en gecontroleerd aan de hand van de openbare README. De repository is de bron van waarheid. #AI #supabase #opensource #postgres #database [pa] Supabase — ਓਪਨ-ਸੋਰਸ Postgres ਬੈਕਐਂਡ, ਪ੍ਰਮਾਣੀਕਰਨ (auth) ਅਤੇ ਰੀਅਲਟਾਈਮ ਦੇ ਨਾਲ ਪੋਸਟਗ੍ਰੇਸ 'ਤੇ ਪ੍ਰਮਾਣੀਕਰਨ, ਸਟੋਰੇਜ, ਅਤੇ ਰੀਅਲਟਾਈਮ API ਦੇ ਨਾਲ ਬਣਾਇਆ ਗਿਆ ਓਪਨ ਸੋਰਸ ਫਾਇਰਬੇਸ ਵਿਕਲਪ। ਰਿਪੋਜ਼ਟਰੀ: supabase/supabase ਤੁਹਾਨੂੰ ਕੀ ਮਿਲਦਾ ਹੈ: • ਵੈੱਬ, ਮੋਬਾਈਲ ਅਤੇ AI ਐਪਸ ਲਈ ਇੱਕ ਹੋਸਟਡ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। • ਤੁਹਾਡੇ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਤੋਂ ਸਿੱਧੇ REST ਅਤੇ GraphQL API ਨੂੰ ਸਵੈ-ਜਨਰੇਟ ਕਰਦਾ ਹੈ। • WebSockets 'ਤੇ ਰੀਅਲਟਾਈਮ ਡੇਟਾਬੇਸ ਤਬਦੀਲੀ ਗਾਹਕੀਆਂ ਦਾ ਸਮਰਥਨ ਕਰਦਾ ਹੈ। ਲੋੜਾਂ: • ਹੋਸਟ ਕੀਤੇ ਪਲੇਟਫਾਰਮ ਲਈ ਕੋਈ ਇੰਸਟਾਲ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ; ਸਿਰਫ਼ ਸਾਈਨ ਅੱਪ ਕਰੋ। ਇੱਕ ਜਨਤਕ ਓਪਨ-ਸੋਰਸ ਪ੍ਰੋਜੈਕਟ ਦਾ ਸੁਤੰਤਰ ਸਾਰ। ਨਿਊਰਲ ਨੈਕਸਸ ਪ੍ਰੋਜੈਕਟ ਲੇਖਕਾਂ ਜਾਂ GitHub ਨਾਲ ਸੰਬੰਧਿਤ, ਸਮਰਥਨ ਜਾਂ ਸਪਾਂਸਰ ਨਹੀਂ ਹੈ। ਵੌਇਸਓਵਰ AI-ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ ਜਨਤਕ README ਦੇ ਵਿਰੁੱਧ ਜਾਂਚਿਆ ਗਿਆ ਹੈ। ਰਿਪੋਜ਼ਟਰੀ ਸੱਚਾਈ ਦਾ ਸਰੋਤ ਹੈ। #AI #supabase #opensource #postgres #database [pl] Supabase — open-source'owy backend Postgres z autoryzacją i funkcjami czasu rzeczywistego Alternatywa open source dla Firebase oparta na Postgres z uwierzytelnianiem, pamięcią masową i interfejsami API czasu rzeczywistego. Repozytorium: supabase/supabase Co otrzymasz: • Udostępnia hostowaną bazę danych Postgres dla aplikacji internetowych, mobilnych i AI. • Automatycznie generuje interfejsy API REST i GraphQL bezpośrednio z bazy danych Postgres. • Obsługuje subskrypcje zmian w bazie danych w czasie rzeczywistym przez WebSockets. Wymagania: • Nie wymaga instalacji platformy hostowanej; wystarczy się zarejestrować. Niezależne podsumowanie publicznego projektu open source. Neural Nexus nie jest powiązany, wspierany ani sponsorowany przez autorów projektu ani GitHub. Nagranie głosowe jest generowane przez sztuczną inteligencję i sprawdzane pod kątem publicznego pliku README. Repozytorium jest źródłem prawdy. #AI #supabase #opensource #postgres #database [pt-BR] supabase — backend Postgres open-source com autenticação e tempo real Alternativa de código aberto ao Firebase, construída sobre o Postgres, com autenticação, armazenamento e APIs em tempo real. Repositório: supabase/supabase O que você ganha: • Fornece um banco de dados Postgres hospedado para aplicativos web, mobile e de IA. • Gera automaticamente APIs REST e GraphQL diretamente do seu banco de dados Postgres. • Suporta assinaturas de alterações de banco de dados em tempo real via WebSockets. Requisitos: • Não é necessário instalar nada na plataforma hospedada; basta se cadastrar. Resumo independente de um projeto público de código aberto. A Neural Nexus não é afiliada, endossada ou patrocinada pelos autores do projeto ou pelo GitHub. A narração foi gerada por IA e verificada com o README público. O repositório é a fonte oficial. #IA #supabase #códigoaberto #postgres #bancodedados [ru] Supabase — бэкенд на базе Postgres с открытым исходным кодом, аутентификацией и поддержкой real-time Альтернатива Firebase с открытым исходным кодом, построенная на Postgres, с аутентификацией, хранилищем и API в реальном времени. Репозиторий: supabase/supabase Что вы получаете: • Предоставляет размещенную базу данных Postgres для веб-, мобильных и ИИ-приложений. • Автоматически генерирует REST и GraphQL API непосредственно из вашей базы данных Postgres. • Поддерживает подписки на изменения в базе данных в реальном времени через WebSockets. Требования: • Для размещенной платформы не требуется установка; просто зарегистрируйтесь. Независимое описание публичного проекта с открытым исходным кодом. Neural Nexus не связан, не поддерживается и не спонсируется авторами проекта или GitHub. Голосовое сопровождение сгенерировано ИИ и проверено на соответствие общедоступному файлу README. Репозиторий является источником достоверной информации. #AI #supabase #opensource #postgres #database [ta] Supabase — அங்கீகாரம் (auth) மற்றும் நிகழ்நேர வசதிகளுடன் கூடிய ஓப்பன் சோர்ஸ் Postgres பேக்எண்ட் அங்கீகாரம், சேமிப்பு மற்றும் நிகழ்நேர API-களுடன் Postgres-இல் கட்டமைக்கப்பட்ட திறந்த மூல Firebase மாற்று. களஞ்சியம்: supabase/supabase நீங்கள் பெறுபவை: • வலை, மொபைல் மற்றும் AI செயலிகளுக்காக ஒரு ஹோஸ்ட் செய்யப்பட்ட Postgres தரவுத்தளத்தை வழங்குகிறது. • உங்கள் Postgres தரவுத்தளத்திலிருந்து நேரடியாக REST மற்றும் GraphQL API-களைத் தானாக உருவாக்குகிறது. • WebSockets வழியாக நிகழ்நேர தரவுத்தள மாற்ற சந்தாக்களை ஆதரிக்கிறது. தேவைகள்: • ஹோஸ்ட் செய்யப்பட்ட தளத்திற்கு நிறுவல் தேவையில்லை; பதிவு செய்தால் மட்டும் போதும். ஒரு பொது திறந்த மூல திட்டத்தின் சுயாதீனமான சுருக்கம். Neural Nexus, இந்த திட்டத்தின் ஆசிரியர்கள் அல்லது GitHub உடன் இணைக்கப்படவில்லை, அவர்களால் அங்கீகரிக்கப்படவில்லை அல்லது நிதியுதவி செய்யப்படவில்லை. குரல் பதிவு AI-ஆல் உருவாக்கப்பட்டு, பொது README உடன் சரிபார்க்கப்பட்டது. களஞ்சியமே உண்மையின் ஆதாரம். #AI #supabase #opensource #postgres #database [te] Supabase — ఆథ్ మరియు రియల్ టైమ్‌తో కూడిన ఓపెన్-సోర్స్ Postgres బ్యాకెండ్ ప్రామాణీకరణ, నిల్వ, మరియు రియల్ టైమ్ APIలతో Postgres ఆధారంగా నిర్మించబడిన ఓపెన్ సోర్స్ Firebase ప్రత్యామ్నాయం. రిపోజిటరీ: supabase/supabase మీకు లభించేవి: • వెబ్, మొబైల్, మరియు AI యాప్‌ల కోసం హోస్ట్ చేయబడిన Postgres డేటాబేస్‌ను అందిస్తుంది. • మీ Postgres డేటాబేస్ నుండి నేరుగా REST మరియు GraphQL APIలను స్వయంచాలకంగా రూపొందిస్తుంది. • WebSockets ద్వారా రియల్ టైమ్ డేటాబేస్ మార్పు సబ్‌స్క్రిప్షన్‌లకు మద్దతు ఇస్తుంది. అవసరాలు: • హోస్ట్ చేయబడిన ప్లాట్‌ఫారమ్ కోసం ఇన్‌స్టాల్ చేయవలసిన అవసరం లేదు; కేవలం సైన్ అప్ చేయండి. ఒక పబ్లిక్ ఓపెన్-సోర్స్ ప్రాజెక్ట్ యొక్క స్వతంత్ర సారాంశం. న్యూరల్ నెక్సస్‌కు ప్రాజెక్ట్ రచయితలు లేదా GitHubతో ఎలాంటి అనుబంధం లేదు, వారిచే ఆమోదించబడలేదు, లేదా స్పాన్సర్ చేయబడలేదు. వాయిస్‌ఓవర్ AI ద్వారా రూపొందించబడింది మరియు పబ్లిక్ READMEతో సరిపోల్చి తనిఖీ చేయబడింది. రిపోజిటరీయే అసలైన ఆధారం. #AI #supabase #opensource #postgres #database [uk] Supabase — open-source Postgres-бекенд з аутентифікацією та реальним часом Альтернатива Firebase з відкритим кодом, побудована на Postgres з автентифікацією, сховищем та API реального часу. Репозиторій: supabase/supabase Що ви отримуєте: • Надає розміщену базу даних Postgres для веб-, мобільних та штучного інтелекту (AI) додатків. • Автоматично генерує REST та GraphQL API безпосередньо з вашої бази даних Postgres. • Підтримує підписки на зміни в базі даних у реальному часі через WebSockets. Вимоги: • Не потрібно встановлювати розміщену платформу; просто зареєструйтесь. Незалежний огляд публічного проекту з відкритим кодом. Neural Nexus не пов'язаний, не схвалений та не спонсорований авторами проекту чи GitHub. Закадровий голос згенеровано штучним інтелектом та перевірено на відповідність публічному README. Репозиторій є джерелом достовірної інформації. #AI #supabase #opensource #postgres #database

5 個開源專案都能幫 AI 工作，從寫程式到找工作 今天的 GitHub 開源熱榜由 ponytail 領先，一天增加 2,079 星。其他上榜專案還包括 Supabase、vLLM、freehire 與 Twenty，涵蓋 AI coding agent、Postgres 平台、LLM serving、求職搜尋及客製化 CRM。 1｜ponytail：讓 AI 少寫程式碼 DietrichGebert/ponytail 2｜supabase：Postgres 開發平台 supabase/supabase 3｜vllm：高效 LLM 推論引擎 vllm-project/vllm 4｜freehire：開源職缺搜尋引擎 strelov1/freehire 5｜twenty：可客製化開源 CRM twentyhq/twenty 資料來源：GitHub Trending（今日新增 star） 每天幫你篩一遍 GitHub 開源熱榜。 排名依 GitHub Trending 當日新增 star 數，僅供參考，不代表推薦或背書。 #GitHub #開源 #程式設計 #開源專案 #GitHubTrending #軟體開發 #ponytail #JavaScript #TypeScript #Python #GitHub熱榜 #Supabase #Shorts

Reminder: new tables will require explicit API grants from October 30 Starting October 30, newly created tables in the public schema on existing Supabase projects will need explicit GRANT statements to be accessible through the Data and GraphQL APIs, including via supabase-js. Existing tables keep their current grants and will continue working. RLS behavior is unchanged, and direct Postgres connections aren’t affected. If your migrations or AI tools create tables, make sure they include the appropriate grants alongside your RLS policies. Full details and SQL examples