Supabase Update, May 2026: everything that shipped, with the dates

The May 2026 timeline

Five concrete dates, four shipped, two scheduled. The two scheduled ones at the right of the row are the breaking changes; the rest are additive.

May 7: the Developer Update, in seven concrete pieces

The monthly Developer Update for May (changelog post 45702) bundled seven shipping items. Two of them, the custom OAuth/OIDC providers and the new server SDK, are the ones most likely to materially change how a project is structured.

1. Custom OAuth/OIDC providers for Supabase Auth. You can now wire any OAuth2 or OIDC identity provider, including GitHub Enterprise and regional IdPs that are not in the built-in list. PKCE is on by default.
2. @supabase/server SDK. A new SDK with first-class context injection, CORS handling, and client creation across Edge Functions, Vercel Functions, Deno, Bun, and Cloudflare Workers. Replaces a fair amount of boilerplate that most projects had copied between projects. See the introducing-supabase-server blog post for the rationale.
3. Branching without Git. You can create a Supabase branch (with its own database, auth settings, and edge functions) directly from the dashboard. Git branching still works; this is for the case where you do not want to spin up a separate repo just to test a schema change.
4. ISO/IEC 27001:2022 certification. Now covers the full platform. Useful concretely for procurement cycles where a buyer's security review previously stalled on the cert.
5. Wrappers v0.6.0. Foreign data wrappers for Postgres. v0.6.0 adds an OpenAPI FDW (turn any OpenAPI-documented HTTP API into a Postgres table), timeout support for the Snowflake wrapper, and full CRUD against Clerk.
6. Terraform Provider v1.9.0. New resources for Edge Functions and Edge Function secrets, plus a network-bans data source. Worth a re-pin if you manage Supabase with Terraform; the older provider just did not have these.
7. Project milestones. The Supabase GitHub repo passed 100,000 stars. The platform passed 0M developers. These are not feature changes; they are the organisational context that explains why an ISO 27001 cert ships this month and not next year.

May 30: the auto-expose default flip

This is the change least likely to be in your inbox and most likely to cause a 4xx in your client app two weeks from now. Until May 30, 2026, a new table in the public schema is automatically reachable via PostgREST and pg_graphql using your anon or authenticated key. After May 30, on new projects, that auto-grant goes away. The behaviour has been opt-in on new projects since April 28, 2026, so this is not a surprise rollout; it is the second half of an already announced two-step.

The auto-grant has always been a footgun on the security side (people forgot to add RLS and effectively published private tables), and the new default closes it. Worth noting: this does not change anything about RLS. If your tables are already protected by row-level policies, the new default just means you also need to remember the GRANT statement. If you do not, the table is invisible to your API key entirely, which is the safer failure mode.

May 26: /v1/oauth/token returns 200 instead of 201

OAuth 2.1 specifies HTTP 200 on a successful token exchange. Supabase's endpoint historically returned 201, which is a quirk most libraries silently tolerate (any 2xx is a success), but a small number of strict clients pin the exact status code in middleware or assertions. After May 26, the response is 200. Same body, same headers.

If you control your OAuth client code, search for an exact-match on the string 201 anywhere it talks to /v1/oauth/token and relax it to res.status >= 200 && res.status < 300. If you rely on an SDK, you are probably already fine; the official libraries treat the entire 2xx range as success.

The JS client: what changed between v2.105.4 and v2.105.5-beta.0

Two stable-line releases this month. Pulled from github.com/supabase/supabase-js/releases.

• v2.105.4 (May 8, 2026): auth, postgrest, and realtime fixes on the stable line. No public API changes. Drop-in.
• v2.105.5-beta.0 (May 11, 2026): passkey and WebAuthn support for browser sign-in, plus a deferred-disconnect behaviour on the realtime client so a transient connection blip does not aggressively tear down active channels.
• v3.0.0-next.25 through v3.0.0-next.29 (May 7 to 11, 2026): the v3 preview line is moving in lockstep. Not stable yet. Useful to track if you have a project that wants the new shape; do not put it in production.

The ChatGPT App is a cloud agent. The local-Mac path looks different.

The headline feature of the month, the official ChatGPT App, lets you point ChatGPT at your Supabase project and ask it questions in natural language. It works through an OAuth handshake; ChatGPT gets scoped access to your project on the server side, and the conversation lives in OpenAI infrastructure. For a lot of teams that is the right tradeoff. For a smaller crowd of macOS users who would rather not put a cloud-side agent on their production database, the alternative path is to drive the Supabase Studio dashboard locally, in a browser logged in to your own account, with voice or text commands.

That is the slot Fazm sits in. It is a macOS-only computer-use agent that controls the browser (and every other app on your Mac) through the macOS accessibility APIs rather than through screen capture and pixel matching. So when you say “open Supabase Studio for the staging project, run the grants migration from this morning, then export the new branch URL”, it reads the dashboard the way VoiceOver does: as a real DOM tree, not as a screenshot to be re-recognised every turn. The authentication is whatever you already have in your browser session. Nothing is uploaded.

This is not a replacement for the ChatGPT App. It is the local path. The ChatGPT App is the right answer if you want a cloud agent your team can share. Fazm is the right answer if you want voice or text control of the Supabase Studio that is already open in your browser, on the Mac in front of you, with the data staying on your machine. The accessibility-API approach also means it works for the rest of your Mac at the same time, which a Supabase-specific integration does not.

What to do this week, before the May 26 and May 30 deadlines

A short list of concrete actions, in the order I would do them.

1. Search your codebase for any literal 201 assertion against /v1/oauth/token. Relax it to a 2xx check. Five minute fix, prevents a confusing outage on May 26.
2. Decide if you want the new PostgREST auto-expose behaviour on any existing project. The default flip only hits new projects on May 30, but you can opt in to the safer behaviour today on existing projects. If you are starting fresh after May 30, writeGRANT USAGE ON SCHEMA public TO anon, authenticated; into your initial migration so you never wonder why a new table returns empty.
3. If you are running supabase-js v2.105.<4, bump to v2.105.4. The realtime fixes are worth it independently of the May changes.
4. If you wanted passkey sign-in, the beta lane (2.105.5-beta.0) is the place. Wait for the stable release if your app is in production.
5. If you have a Terraform-managed Supabase project, pin to hashicorp/supabase v1.9.0 and add an Edge Functions resource. The old workaround (managing functions out-of-band) can be retired.
6. If you were a contributor to the Stripe Sync Engine, follow the repo handoff to Stripe's GitHub org. Existing integrations keep working without changes.