The Supabase release log for May 2026, and the two defaults that quietly break Claude Code migrations

The full May 2026 release log

Ten entries in chronological order. Each one has a one-line note on what it means for someone who runs an AI coding agent against a Supabase backend, not just a press cycle.

1. May 1, 2026

   OAuth token endpoint status code change (201 to 200)

   The /v1/oauth/token endpoint moved from HTTP 201 Created to HTTP 200 OK for OAuth 2.1 compliance. The response body did not change. Any client that asserts on the exact status code instead of treating 2xx as success needs a one-line update.

   Why it matters for an agent run: Quiet, but the kind of change that surfaces a week later when a CI integration that was over-asserting on 201 breaks for no obvious reason.

   Source: Supabase changelog

2. May 7, 2026

   Developer Update: custom OAuth/OIDC, Data API defaults, @supabase/server SDK

   The monthly developer post bundled four things. First, you can now plug in any OAuth 2.0 or OIDC provider, including GitHub Enterprise and regional IdPs, with PKCE on by default. Second, new projects can opt out of automatic Data API exposure for public schema tables, with explicit grants required; this becomes the default for all new projects on May 30. Third, a new @supabase/server SDK handles auth, client creation, CORS, and context injection across Edge Functions, Vercel Functions, Deno, Bun, and Cloudflare Workers. Fourth, branching without Git is now the default.

   Why it matters for an agent run: The Data API default is the one to circle. Code generated against the old default produces tables that are quietly invisible to PostgREST and GraphQL once you create a project after May 30.

   Source: Supabase changelog (Developer Update)

3. May 12, 2026

   Postgres 14 deprecated, auto-upgrade scheduled July 1, 2026

   Supabase confirmed Postgres 14 is deprecated and will be auto-upgraded on hosted projects starting July 1, 2026. You can run the upgrade manually before that date. The recommended target is Postgres 17.

   Why it matters for an agent run: A scheduled major upgrade is the right moment to also enable pg_graphql 1.6 (introspection off), since both rollouts converge in the same window.

   Source: Supabase changelog

4. May 18, 2026

   Self-hosted Supabase: three breaking changes

   For self-hosted deployments only: Analytics and Vector became opt-in rather than on by default, Supabase Studio switched its database role from supabase_admin to postgres, and the default Docker Compose Postgres image moved from PG 15 to PG 17. Each is breaking for an existing self-hosted stack.

   Why it matters for an agent run: Nothing to do on Supabase Cloud, but if you self-host you want all three pinned in a single planned upgrade window rather than discovered piecemeal.

   Source: Supabase changelog

5. May 25, 2026

   Temporary token-based database access (preview)

   A feature preview for short-lived, scoped tokens that grant temporary database access. Intended for cases where a client or process needs Postgres credentials but you do not want to mint a long-lived password.

   Why it matters for an agent run: The right primitive for AI agents that need scoped Postgres access for one task. Easier to revoke if a session goes wrong than rotating a permanent password.

   Source: Supabase changelog

6. May 25, 2026

   pg_graphql 1.6.0: GraphQL introspection disabled by default

   Starting with pg_graphql 1.6.0, rolling out to new projects from June 15, 2026, __schema and __type introspection queries are disabled by default to reduce API enumeration. Regular data queries are unaffected. Existing projects keep the current behavior until pg_graphql is upgraded.

   Why it matters for an agent run: Any agent or local tool that builds its UI by introspecting the GraphQL schema (graphiql, Apollo Studio, schema-first code generators) needs an explicit opt-in on a new project after June 15.

   Source: Supabase changelog

7. May 27, 2026

   Supabase agent-skills v0.1.5 ships

   Supabase published v0.1.5 of agent-skills at github.com/supabase/agent-skills, an open-source skill that teaches Claude Code and 17 other agents how to write Supabase code that matches current defaults. It installs through the Claude Code plugin marketplace and includes an inline security checklist: never use user_metadata for authorization, never expose service_role on the frontend, always enable RLS on a new table, and (the new line) always emit the three GRANT statements after CREATE TABLE on a project that uses the May 30 default.

   Why it matters for an agent run: This is the change that matters most for anyone running Claude Code against a Supabase backend. Without the skill loaded, a fresh project after May 30 will look like it has a Row Level Security bug; with it, the agent emits the grants on the same migration.

   Source: Supabase blog

8. May 28, 2026

   Passkeys for Supabase Auth (beta)

   A passwordless, phishing-resistant credential built on WebAuthn entered beta. Users sign in with Face ID, Touch ID, Windows Hello, a device PIN, or a hardware security key. Supabase Auth stores only the public key; the private key stays with the authenticator. The JavaScript SDK adds two new methods that wrap the full WebAuthn ceremony.

   Why it matters for an agent run: The cleanest path to phishing-resistant sign-in for a small-team SaaS, without having to glue WebAuthn primitives together yourself.

   Source: Supabase changelog

9. May 2026

   ISO/IEC 27001:2022 certification

   Supabase achieved ISO/IEC 27001:2022 certification covering the information security management system across the platform.

   Why it matters for an agent run: Procurement-adjacent. Does not change a single line of code, but unblocks the security review that comes after.

   Source: Supabase changelog

10. May 2026

    Stripe Sync Engine moved to Stripe; Stripe Marketplace app GA

    The Stripe Sync Engine project moved from the Supabase GitHub organization to Stripe's and is now maintained by Stripe as open source. The Supabase app in the Stripe Marketplace also reached general availability.

    Why it matters for an agent run: Useful context if you are wiring billing into a Supabase project, since the canonical sync engine repo has a new home.

    Source: Supabase changelog

What Claude Code writes vs. what the May 30 default actually needs

Same task, same prompt ("add an invoices table with org-scoped RLS"), same Claude Code session. The first block is the migration Claude Code reliably emits from training data; the second is the extra block the May 30 default requires before the table is reachable through any of the Supabase client libraries.

-- What Claude Code typically writes (trained on pre-May-2026 examples).
-- Applies cleanly on a project created before May 30, 2026,
-- and the table is reachable via PostgREST and supabase-js automatically.

create table public.invoices (
  id uuid primary key default gen_random_uuid(),
  org_id uuid not null,
  amount_cents int not null,
  status text not null default 'draft',
  created_at timestamptz not null default now()
);

alter table public.invoices enable row level security;

create policy "org members can read"
  on public.invoices for select
  using (org_id = auth.jwt() ->> 'org_id');

After May 30 you also need the three GRANT statements. Without them the table is invisible to anon, authenticated, and service_role callers, and the response from GET /rest/v1/invoices is silent.

-- What you also need on a project created on or after May 30, 2026.
-- Without these three grants, /rest/v1/invoices returns nothing
-- and the failure looks like a Row Level Security bug.

grant select on public.invoices to anon;

grant select, insert, update, delete on public.invoices to authenticated;

grant select, insert, update, delete on public.invoices to service_role;

The exact three statements come from the April 28 changelog post that announced the change. They are also the three lines the supabase/agent-skills v0.1.5 checklist now adds to its required output for a CREATE TABLE on a project that uses the May 30 default.

What loading supabase/agent-skills actually changes in a Claude Code session

The skill is not magic. It is a folder of instructions, a checklist, and a few helper scripts that Claude Code (and the other 17 listed agents) loads at session start. What it changes is the prior the agent operates with: instead of producing the SQL it remembers from older Supabase tutorials, it produces SQL that matches the current defaults.

The checklist in the agent-skills CLAUDE.md file covers items that come up on almost every Supabase project: never use user_metadata for authorization, never expose service_role on the frontend, always enable RLS on a new table, always use security_invoker = true on a view that fronts a sensitive table, never invent CLI commands (which agents have a measurable habit of doing). The v0.1.5 line added on May 27 is the GRANT requirement that lines up with the May 30 Data API default.

For Claude Code, installation is one plugin install through the marketplace. Once installed, the skill is loaded automatically on any session whose working directory contains a Supabase project marker. The skill applies inside any host that runs Claude Code: the terminal, an IDE plugin, or a native wrapper like Fazm, all the same way, because the skill is loaded by Claude Code itself rather than by the host.

The Fazm-specific note is narrow: a Supabase migration plan tends to span many turns (schema design, policy design, grant policy, test seed data, edge function deploy), and Fazm windows do not auto-compact context for the lifetime of the window. The agent keeps the entire prior schema discussion live when it writes the next migration, which is exactly the part that gets summarized away in a long terminal session that compacts on its own.

Questions about the May 2026 Supabase release