Supabase Release Notes

What's Changing?#

The week of June 1, 2026, the analytics (Logflare) and vector services will be removed from the default docker-compose.yml and moved into an opt-in overlay file: docker-compose.logs.yml (PR #45327).

The default docker compose up -d will start a leaner stack without log aggregation. To keep using Logs Explorer in Studio, you'll need to include the overlay:

docker compose -f docker-compose.yml -f docker-compose.logs.yml up -d

The base docker-compose.yml will also set ENABLED_FEATURES_LOGS_ALL: false on Studio by default, so the Logs menu item won't appear in the UI unless you bring up the overlay.

Why?#

• Analytics (Logflare) is a heavy service in the default self-hosted Supabase stack. Making it an opt-in reduces CPU and memory footprint.
• Studio, Auth, Storage, PostgREST, and Realtime all work without analytics or vector.

Am I Affected?#

You are affected if all of the following are true:

• You run self-hosted Supabase from the ./docker directory
• You pull updates from master without overriding the compose invocation
• You actively use Logs Explorer in Studio

You are not affected if you:

• Use the Supabase platform
• Use the Supabase CLI for local development (supabase start) - it's a different deployment option
• Don't use Logs Explorer (analytics and vector silently going away)
• Already maintain a customized compose configuration

What Should I Do?#

If you use Logs Explorer

Add the overlay to your docker compose invocation:

docker compose -f docker-compose.yml -f docker-compose.logs.yml up -d

You'll need to include both -f flags on every docker compose command (up, down, logs, ps, etc.) for the overlay to apply consistently. If that's inconvenient, set COMPOSE_FILE=docker-compose.yml:docker-compose.logs.yml in your .env and the flags become implicit.

If you don't use Logs Explorer

No action needed. Pull the new compose files and docker compose up -d will just work, with a smaller resource footprint. Existing analytics and vector containers and their volumes will stop being managed - you can remove them once you've confirmed the stack is healthy:

docker compose rm -f -s -v analytics vector

Rollout

Date Change 2026-05-18 This changelog published 2025-06-03 Default flips in the next self-hosted Supabase release Original source

What's Changing?

The week of June 15, 2026, the default docker-compose.yml in self-hosted Supabase will switch the database role used by Studio and postgres-meta from supabase_admin to postgres:

• studio.environment.POSTGRES_USER_READ_WRITE will default to postgres
• meta.environment.PG_META_DB_USER will default to postgres

This aligns self-hosted Supabase with the platform behavior introduced in late 2022, which removed superuser access from the dashboard SQL editor and shifted ownership of user-created objects to postgres. Self-hosted has been running with the legacy behavior until now.

⚠️ Existing instances that pull this change need to run a one-time ownership migration script for the public schema, or new operations from Studio may fail on objects still owned by supabase_admin.

Why?

• Self-hosted has been three-plus years behind the platform on this. Behavior between deployment models should be consistent.
• The postgres role is non-superuser, so this reduces the privilege surface used by Studio's day-to-day operations.
• Migrations and scripts that work on the platform may currently fail on self-hosted because of the ownership mismatch - this closes that gap.

Am I Affected?

You are affected if all of the following are true:

• You run self-hosted Supabase from the ./docker directory
• You pull updates from master without overriding POSTGRES_USER_READ_WRITE or PG_META_DB_USER
• You have an existing instance with database objects created via Studio (which would currently be owned by supabase_admin)

You are not affected if you:

• Use the Supabase platform - this has been the default since 2022
• Use the Supabase CLI for local development (supabase start) - it's a different deployment option
• Are starting a fresh self-hosted deployment - objects created via Studio will be owned by postgres from the start

What Should I Do?

If you have an existing self-hosted Supabase instance, follow the Remove superuser access guide:

• Run the included script to reassign ownership of objects in the public schema from supabase_admin to postgres:

utils/reassign-owner.sh

• Pull the new docker-compose.yml (or manually set POSTGRES_USER_READ_WRITE: postgres and PG_META_DB_USER: postgres if you maintain a customized compose file)
• Restart the stack
• Verify in the Studio SQL editor that select current_user; returns postgres

The script only touches the public schema. Supabase-managed schemas (auth, storage, realtime, etc.) and any custom schemas you've created are left intact. If you have objects in custom schemas that you want migrated, you'll need to reassign their ownership manually.

If you'd rather defer this for now, set POSTGRES_USER_READ_WRITE and PG_META_DB_USER back to supabase_admin in your override file. This is a default change, not a removal - but we recommend completing the migration soon to stay aligned with platform behavior.

Rollout

Date Change

2026-04-27 Migration guide published in self-hosting docs

2026-05-18 This changelog published

2026-06-17 Default flips in the next self-hosted Supabase release

Original source

What’s Changing?#

The week of June 15, 2026, the default db image in the self-hosted Supabase docker-compose.yml will move from Postgres 15 to Postgres 17.

⚠️ If your database uses timescaledb, plv8, plcoffee, or plls, you cannot upgrade to the Supabase images of PG 17 - these extensions are no longer included.

This affects the default image tag only. Pinning to a specific supabase/postgres 15.x tag will continue to work, and the PG 15 images on Docker Hub will remain available.

Existing Postgres 15 data directories will not auto-upgrade. Bringing up the new compose file against a PG 15 volume will fail to start - PG 17 cannot read a PG 15 data directory directly.

Why?#

• Postgres 17 is what we currently default to on the Supabase platform, and aligning the self-hosted default keeps behavior consistent across deployment models.
• PG 15 has been the self-hosted default for a long time; PG 17 brings several years of upstream improvements.
• Pinning to PG 15 remains supported for anyone who needs more time.

Am I Affected?#

You are affected if all of the following are true:

• You run self-hosted Supabase from the ./docker directory
• You pull updates from master without pinning the supabase/postgres image tag
• Your existing data is on Postgres 15

You are not affected if you:

• Use the Supabase platform
• Use the Supabase CLI for local development (supabase start) - it's a different deployment option
• Pin to a specific Postgres 15 image and don't update
• Are starting a fresh self-hosted deployment - you'll get PG 17 from the start after the default is switched

What Should I Do?#

If you have a self-hosted Supabase instance with data to preserve, you have two options.

Option 1: Upgrade in place (via a utility script)

This is the recommended path for existing data. Read the upgrade how-to guide to learn more.
Before running the script, create your own backup of ./volumes/db/data and the pgsodium key.
The script will perform the following steps (high-level):

• Pulls the Postgres 17 binaries and upgrade scripts
• Stops the Supabase stack
• Disables incompatible extensions and runs pg_upgrade in a temporary PG 15 container
• Re-enables extensions, applies patches, and runs VACUUM ANALYZE in a temporary PG 17 container
• Swaps data directories (the original is kept as ./volumes/db/data.bak.pg15)
• Restarts the stack on Postgres 17

Rollback to PG 15 is supported - the script keeps the original data directory, and the guide has the exact steps.

Option 2: Stay on Postgres 15 and migrate later

Pin the PG 15 image in your docker-compose file:

services:
  db:
    container_name: supabase-db
    image: supabase/postgres:15.x

This is the lowest-friction option if you're not ready to upgrade. We'll continue publishing PG 15 images, but new features and fixes will land on PG 17 first (and subsequently on PG 18).

Rollout

Date Change
2026-04-08 PG 17 available as opt-in
2026-04-08 Upgrade guide published in self-hosting docs
2026-05-18 This changelog published
2026-06-17 Default flips in the next self-hosted Supabase release

Original source

Supabase support for Postgres 14 is deprecated as of 1st July 2026 and support for it will be fully removed from this date on.

All projects still on a deprecated Postgres version on the 1st July 2026 will automatically be upgraded to the latest Postgres version available. If extensions that are no longer supported are being used, the projects will be paused instead and no longer serve traffic.

Why upgrade?

Postgres 17 brings significant improvements to performance, security, and reliability. Depending on your current version, upgrading gives you access to between 2–3 years of cumulative fixes and enhancements—over 700 individual improvements if you're coming from Postgres 14.

Key benefits include:

• Performance: Faster vacuuming, improved query planning, better parallel query execution, and optimised memory handling
• Security: Multiple CVE fixes and enhanced authentication options including configurable SCRAM iteration counts
• New capabilities: The MERGE command, logical replication on standbys, incremental backup support, and improved partitioning performance
• Better observability: New pg_stat_io view and enhanced monitoring across the board

Before you upgrade

1. Plan for downtime

The upgrade process requires taking your project offline temporarily. Smaller databases typically complete in around 15 minutes, while larger databases can take an hour or more depending on your compute size and disk configuration (an estimate of the downtime is provided when you begin the upgrade in the dashboard). We recommend scheduling your upgrade during a low-traffic period. If you're unsure what to expect for your project, please reach out to our Support team for guidance.

2. Test your applications

Using a new Postgres 17 project, confirm that your existing applications work and that there are no compatibility issues or breaking changes that impact you.

3. Check for deprecated extensions

If your project uses any of the following extensions, you'll need to remove them before upgrading to Postgres 17:

• timescaledb
• plv8, pls, plcoffee
• pgjwt

These extensions are no longer included in Postgres 17 on Supabase (see changelog entry). You can check which extensions are currently installed by running SELECT * FROM pg_extension; or by visiting your Extensions dashboard.

For guidance on alternatives and migration paths, please see our upgrade documentation.

4. Prepare your project

You can reduce the time it takes for your project to upgrade by performing a vacuum on larger tables, reindexing larger indexes and removing/archiving any unused data in the database.

How to upgrade

Those organization owners with active projects on Postgres 14 will receive a series of emails, starting from this week, listing the projects they own that need upgrading and outlining the steps required.

You can upgrade directly from your dashboard:

• Go to Project Settings → Infrastructure
• Click Upgrade project
• Follow the prompts to complete the upgrade

Direct link: https://supabase.com/dashboard/project/_/settings/infrastructure

Questions?

If you're unsure whether your project is ready to upgrade, or if you have questions about the deprecated extensions, our Support team is here to help.

Thanks for building with Supabase.

— The Supabase Team

Original source

Here's everything that happened with Supabase in the last month:

Custom OAuth/OIDC providers for Supabase Auth

Connect any OAuth2 or OpenID Connect identity provider to your Supabase project, including GitHub Enterprise, regional IdPs, and any standards-compliant provider, with PKCE enabled by default.

[Blog]

New tables in the public schema are no longer auto-exposed to the Data API

Starting April 28, new Supabase projects can opt out of automatic Data API exposure for public schema tables. Explicit Postgres grants are now required to make a table reachable via PostgREST or GraphQL. This becomes the default for all new projects on May 30.

[GitHub Discussion]

Supabase is now ISO 27001 certified

Supabase is certified to ISO/IEC 27001:2022, covering the information security management system across the entire platform.

[Blog]

Stripe Sync Engine moves to Stripe

The Stripe Sync Engine, originally built by Supabase, is now part of the Stripe GitHub org. It is open source and maintained by Stripe going forward.

[Blog]

Supabase brand survey

Help shape the direction of Supabase. The brand survey takes a few minutes and closes soon.

[Take the survey]

@supabase/server

A new SDK that handles auth, client creation, CORS, and context injection across runtimes. Works on Edge Functions, Vercel Functions, Deno, Bun, and Cloudflare Workers.

[Blog] [Docs]

Quick Product Announcements

• The Supabase app in the Stripe Marketplace is now generally available. [Stripe Marketplace]
• Branching without Git is now the default. Create branches directly from the dashboard without a GitHub integration. [Blog]
• Data API settings revamped: new per-table and per-function toggles let you control which tables are exposed to PostgREST and GraphQL, with a default-privileges switch at project creation. [Docs]
• The Supabase changelog now has RSS feeds, tag filtering, and a .md feed, plus links to copy any entry as Markdown or ask Claude/ChatGPT. [Changelog]
• Wrappers v0.6.0 ships with a new OpenAPI FDW, Snowflake timeout support, Clerk CRUD, and several bug fixes. [GitHub] [Docs]
• Supabase Agent Skills: an open-source set of instructions that teach AI coding agents how to build on Supabase correctly. [Blog]
• Terraform Provider v1.9.0 adds Edge Functions resource, Edge Function secrets resource, and a network bans data source. [Docs]

Made with Supabase

• Replist: Track your repertoire, sharpen your practice, and connect with the musicians you play with. [Website]
• Grepture: Trace, evaluate, and protect every LLM call. Drop-in SDK. 80+ detection rules. [Website]
• Causo: Agents that connect you with best fit partners at VCs. [Website]
• Screenfully: An app demo creator on your phone. No need to connect to a Mac. [Website]
• Anamap: Cartos by Anamap is an AI agent that investigates your dashboards, site behavior, and code releases to find the root cause of metric drops in plain English. [Website]
• Crewform: Build your AI team with Crewform. Orchestrate specialized, autonomous agents to collaborate on complex tasks and connect outputs to your stack. [GitHub]

Community Highlights

• The Supabase GitHub repo hit 100K stars and 8 million developers. [Blog]
• Introducing the OSSCAR: An index of the fastest-growing open-source orgs. [Blog]
• The State of Startups 2026 survey is still open. [Survey]
• How I Scaled My NextJS + Supabase App to 25,000 Users [YouTube]
• Stop Building Custom Auth — Auth0 vs Supabase: One Saved Us 3 Months of Engineering Work [Blog]

This discussion was created from the release Developer Update - May 2026.

Original source

The /v1/oauth/token endpoint currently returns HTTP 201 Created on success. On May 22, 2026, this will change to HTTP 200 OK.

Why

OAuth 2.1 (section 3.2.3) mandates a 200 response from token endpoints. Returning 201 is non-compliant and has caused token exchange failures with some strict OAuth clients.

Am I affected?

You're only affected if your integration explicitly checks for a 201 status code from this endpoint. For example, the following popular client implementations check for a successful 2XX range and are unaffected:

• MCP TypeScript SDK — uses response.ok
• Vercel AI SDK (@ai-sdk/mcp) — uses response.ok
• axios — resolves for any 2XX by default

If you're unsure, search your codebase for explicit 201 checks against this endpoint.

What should I do?

Rather than hardcoding a check for either 200 or 201, we recommend checking for a successful 2XX response range — e.g. response.ok in the Fetch API. This is consistent with how popular OAuth client libraries handle token responses and will be resilient to either status code.

Timeline

Date Event

May 1, 2026 Announcement published

May 26, 2026 Change takes effect

Original source

New tables in the public schema will no longer be exposed to the Data API automatically.

When this change takes effect

Starting today (April 28, 2026), you can create new Supabase projects where tables in the public schema are not exposed to the Data API and GraphQL API by default. You can enable this setting at project creation.

On May 18, 2026, pg_graphql will not be enabled by default. More details here.

On May 30, 2026, this setting becomes the default for all new projects.

On October 30, 2026, the setting will be applied it to all existing projects.

Once the change is rolled out to your project, new tables you create in public schema require an explicit opt-in (via a Postgres grant) before the Data API can see them. Existing tables are not affected in your project, they keep their current grants and stay reachable. This change applies to projects that use the Data API, Supabase's auto-generated REST and GraphQL layer, which is what supabase-js and our other client libraries call. If your app reads and writes Postgres over a direct connection (via psql, ORM or an app server with a connection string), this change will not affect you.

What's changing

Previously, when you create a Supabase project with default settings, select, insert, update, and delete are granted to every table in the public schema to the anon, authenticated and service_role roles. Every table you create becomes reachable via the Data API on creation.

From today, the project creation screen includes a setting to opt out of those default grants. When the “Automatically expose new tables” checkbox is unchecked, you opt-in to the new behavior and tables aren’t exposed to the Data API by default. On May 30, 2026 the opt-out becomes the default for all new projects.

RLS behavior remains unchanged. Grants are a separate layer: they control whether a role can access a table at all, while RLS controls which rows that role can see.

If a grant is missing, PostgREST returns a clear error rather than a silent failure:

{
  "code": "42501",
  "message": "permission denied for table your_table",
  "hint": "Grant the required privileges to the current role with: GRANT SELECT ON public.your_table TO anon;"
}

The hint shows you which role is missing which privilege, along with the GRANT needed to fix it.

Before → After

Step Before After Create table in public Table is reachable via Data API on creation Table exists but is not reachable via Data API grant to anon / authenticated / service_role Implicit, via default privileges Required, explicit grant statement alter table ... enable row level security Remains the same Remains the same create policy ... Remains the same Remains the same

Why

When Supabase launched, a human reviewed each schema change and enabled RLS on new tables as they went. The default grants made this convenient: create a table, and it showed up in your client.

That model doesn’t scale, and it’s easy to accidentally expose new tables before you’ve secured them.Today, agents, CLI scripts, and AI platforms create tables too, and many of those operations do not have a human reviewing the diff.

Explicit grants make access a deliberate, code-level decision. The PostgREST error response above includes a precise hint, so an agent can self-correct when a grant is missing instead of producing a broken request.

Without a grant, the API cannot see the table, regardless of how you created it (SQL editor, migrations, Management API, MCP, CLI, or an AI coding tool). Postgres enforces this at the role layer, so the guarantee holds regardless of the creation path.

We’re moving the platform toward declarative code. Explicit Postgres grants are reviewable, diffable, and greppable. They also give you per-role control: anon and authenticated need different privileges in most schemas, and an explicit grant makes that difference visible in your migrations. This was always possible, now it's the default.

Currently, the default grants expose every table in public over the Data API on creation, including tables a developer forgot to protect.

This is the next step in a series of platform default changes we have shipped over the past quarter:

• a Data API exposure badge in the Dashboard
• granular per-table grants
• an RLS-on-by-default toggle
• the schema enumeration restriction in March

Who is affected

You are unaffected if you only talk to your database over a direct Postgres connection--you can stop reading.

You need to act if any of the following is true:

• Your app reads or writes tables in the public schema via the Data API (PostgREST, GraphQL, supabase-js, any of the client libraries, or direct HTTP to /rest/v1/ or /graphql/v1)
• Your migrations or provisioning flow create tables in public without explicit GRANT statements.
• Your AI coding tool, CLI script, or Management API call creates tables and expects them to be reachable over the Data API on creation.

The change reaches you on one of three dates:

• From Today, if you opt out of the "Automatically expose new tables and functions" setting during project creation.
• May 30, 2026, when the new behavior becomes the default for all new projects.
• October 30, 2026, when the new behavior is enforced on all existing projects.

Between now and then, Security Advisor will flag affected tables, and we’ll email active projects so you can review access, add grants, and verify your app.

What to do

For new tables you want to expose via the Data API, make explicit grants part of your table-creation flow. Without an explicit GRANT, a role will not have access to the created table.

Treat these three steps as a unit. If the grant is missing, Postgres rejects the query before RLS comes into play.

-- 1. Grant the privileges the role needs
grant select on public.your_table to anon;
grant select, insert, update, delete on public.your_table to authenticated;
grant select, insert, update, delete on public.your_table to service_role;

-- 2. Enable RLS
alter table public.your_table enable row level security;

-- 3. Add the policies you need
create policy "users can read their own rows"
on public.your_table
for select
to authenticated
using (auth.uid() = user_id);

If you use an AI coding tool to create tables, update its system prompt or adopt the Supabase agent skill, which includes the grants step, and which we keep updated as the platform changes. Skills are easy to install, and handle grants correctly by default. Agents can self-correct from the PostgREST error hint returned as well.

If you run your own migration framework, or a platform that provisions Supabase projects for your own customers, bundle the GRANT statements alongside your ENABLE ROW LEVEL SECURITY and policy statements in the same migration.

Opting in on existing projects

You do not have to wait for October 30. To adopt the new behavior on an existing project today, run the same revoke statements the dashboard runs at project creation.

Open the SQL Editor for your project and run:

-- Stop Postgres from granting default privileges on future objects in public
alter default privileges for role postgres in schema public;
revoke select, insert, update, delete on tables from anon, authenticated, service_role;
alter default privileges for role postgres in schema public;
revoke usage, select on sequences from anon, authenticated, service_role;

These four statements change the defaults for future tables and sequences that the postgres role creates in the public schema.

Existing objects keep their current grants, so your running app stays reachable.

From this point on, new tables you create in public schema need explicit GRANT statements before the Data API can see them.

If you also want to tighten grants on existing tables you do not want reachable via the Data API, revoke them per table:

revoke all on table public.your_table from anon, authenticated, service_role;

The Data API exposure badge in the Table Editor and the Security Advisor list the tables worth reviewing.

FAQ

Does this affect tables in the storage, auth, realtime, or custom schemas?

No. The change touches default privileges in the public schema. Tables in storage, auth, realtime, and any custom schemas you expose via the Data API keep their current grants and their current defaults.

I opted in on an existing project, created new tables, and my app is broken. How do I roll back?

Open the SQL Editor and run two blocks.

1. Restore defaults for future tables
   Future tables will now behave as they did before the revoke:

alter default privileges for role postgres in schema public;
grant select, insert, update, delete on tables to anon, authenticated, service_role;
alter default privileges for role postgres in schema public;
grant usage, select on sequences to anon, authenticated, service_role;

1. Fix existing tables
   alter default privileges only affects future objects, so tables you created since the revoke stay without grants. Grant them in bulk:

grant select, insert, update, delete on all tables in schema public to anon, authenticated, service_role;
grant usage, select on all sequences in schema public to anon, authenticated, service_role;

After running both blocks, your project matches the pre-revoke state. If you added tables you want to keep private, revoke those individually after the bulk grant:

revoke all on table public.your_private_table from anon, authenticated, service_role;

Rollout timeline

Date Milestone User action 2026-04-28 Changelog published; opt-in toggle available at project creation; docs updated Try it on a test project; adapt your provisioning flow 2026-05-30 New behavior becomes the default for all new projects New-project workflows must include explicit GRANT statements 2026-10-30 New behavior enforced on all existing projects Migration must be complete; tables without explicit grants stop being reachable via the Data API

Communications timeline

We email owners and admins of every active project, including projects with no Security-Advisor-flagged tables today.

After October 30, any new table created in public without an explicit grant stops being reachable via the Data API, so a project with no flagged tables today still breaks the first time someone adds a new one.

From today through October 30, the Security Advisor flags affected tables per project and shows the remediation SQL, so you do not have to hunt for them yourself.

Date Channel Audience 2026-04-28 This changelog post Public 2026-05-07 April monthly newsletter All subscribers 2026-05-13 Email: first notice of the May 30 change for new projects Owners and admins of all active projects 2026-05-27 Email: final reminder before the May 30 change for new projects Owners and admins of all active projects 2026-09-23 Email: five-week notice before the October 30 change for existing projects Owners and admins of all active projects 2026-10-23 Email: final notice, one week before change for existing projects Owners and admins of all active projects

If you have a question, create a support ticket here.

Original source

Verify the correctness of your RLS policies with the RLS tester

Verifying the correctness of your RLS policies set up has always been a gap, as highlighted by a number of GitHub discussions like here and here. As such, we're piloting a dedicated UI for RLS testing (using role impersonation as the base), in which you'll be able to

• Run a SQL query as a user (not logged in / logged in - this is the role impersonation part)
• See which RLS policies are being evaluated as part of the query
• And hopefully be able to debug which policies are not set up correctly

(Side note) We also added partial support for testing client library code instead of just SQL

This is powered by the AI Assistant which will then infer the code into SQL

e.g

const { data }  = await client.from('colors').select('*')

Given that this is by AI, as always do verify the output!

Note: Only SELECT queries are supported for now to simplify things. Testing mutation queries (INSERT, UPDATE, DELETE) could trigger side effects such as triggering a database trigger, especially if it involves an external request such as an edge function or HTTP call - we're keeping them out of this preview while we work out a safe way to support them.

Changes are currently set as a feature preview which you can access by clicking on your Profile picture in the top navigation bar . We'll iterate as we get feedback from everyone so please do let us know what you think! 🙂🙏

Related PR: https://github.com/supabase/supabase/pull/45121

What we'd like to know from you

• Any bugs or issues that you might have run into while using the RLS tester
• Any ideas or suggestions that you reckon will improve the DX based on how you currently verify the correctness of your RLS policies
• Feel free to leave any feedback in this thread too! (Both good and bad!) 🙂🙏

Original source

All official Supabase client libraries now automatically retry failed database queries when they encounter transient network errors — no code changes required.

What changed

When a GET or HEAD request to PostgREST fails with a transient error (HTTP 520, HTTP 503, or a network-level failure), the client transparently retries the request up to 3 times with exponential backoff (1s → 2s → 4s, capped at 30s). Each retry includes an X-Retry-Count header so server-side logs can observe retry behavior.

Only idempotent methods (GET and HEAD) are retried. POST, PATCH, PUT, and DELETE requests are never retried automatically.

Versions

Library Version

supabase-js v2.102.0

supabase-swift v2.43.0

supabase-flutter (postgrest_dart) v2.7.0 (supabase_flutter v2.12.2+)

supabase-py v2.29.0

Configuration

Retries are enabled by default. You can opt out globally or per-request:

JavaScript

// Disable globally
const supabase = createClient(url, key, {
  db: { retryEnabled: false }
})

// Disable per request
const { data } = await supabase.from('table').select().retry(false)

Swift

// Disable globally
let client = PostgrestClient(url: url, headers: headers, retryEnabled: false)

// Disable per request
let data = try await client.from("table").select().retry(enabled: false).execute()

Flutter/Dart

// Disable globally
final client = PostgrestClient(url, retryEnabled: false);

// Disable per request
final data = await supabase.from('table').select().retry(enabled: false);

Python

# Disable per request
data = supabase.table("table").select("*").retry(False).execute()

Original source

We are changing how taxes are calculated on your Supabase invoices for your organizations.

What's changing

Within the next several weeks, applicable taxes (such as sales tax, VAT, or GST) will be included on your Supabase invoices based on your billing address. This change is part of our ongoing tax compliance efforts.

When will this be changing?

The rollout of these changes will be incremental, beginning on May 1 and completing by June 30.

What this means for you

Tax will be assessed using the billing address associated with your organization in accordance with tax law in that location. Please review your organization's billing settings to make sure your billing address and Tax ID (e.g. VAT ID, GSTIN, EIN, ABN), if applicable, are accurate and up to date. A valid Tax ID ensures you're correctly classified for tax purposes and may affect how tax is applied to your invoices.

If you have any questions, please check our FAQ for more information.

Original source

Experimental: Declarative Schema Management with pg-delta

We've been working on a new way to handle database schema changes in the Supabase CLI, and it's now at a point where we want people to try it and tell us what they think.

TL;DR

The CLI now ships with pg-delta, our own Postgres schema diffing engine, and an experimental declarative schema workflow on top of it. Basically: you describe your schema as SQL files, run a command, and the CLI generates the migration for you. No more writing migrations by hand if you don't want to.
Available today behind an experimental flag. This is still very much alpha, things will break, coverage is not complete yet. We want your feedbacks.

Why we built our own

Schema diffing in the CLI has been relying on third-party tools (migra, pgAdmin) and each one comes with its own set of issues, missing coverage, and maintenance problems. On top of that, the whole migration workflow has always been imperative: you write the migration yourself, or you diff against a live database and hope it catches everything.

We looked at existing diffing tools but none of them really fit what we needed. Most of them carry a lot of legacy support for older Postgres versions, and we didn't want that tech debt. pg-delta only targets Postgres 15+, which lets us start clean and take advantage of newer catalog features without workarounds. More importantly, we want a tight integration with all of Supabase's features long term: all the extensions we ship, auth/storage schemas, RLS policies, the whole platform. Building on top of someone else's diffing engine means we'd always be fighting upstream to get Supabase-specific stuff supported. Owning the diffing layer gives us full control over that.

A lot of developers, especially those coming from ORMs or tools like Terraform, expect something more declarative: you describe what the schema should look like, and the tooling figures out the diff. We wanted to offer that.

What's new

pg-delta as a diffing backend

@supabase/pg-delta is our own schema diff engine, written in TypeScript from scratch. It lives in the supabase/pg-toolbelt monorepo alongside pg-topo (topological sorting for DDL statements). You can already use it as the diffing backend for supabase db diff:

supabase db diff --use-pg-delta

It also supports explicit source/target references now:

supabase db diff --from migrations --to local --use-pg-delta

Declarative schema workflow

Everything goes through a single command: supabase db schema declarative sync.

One thing we cared about: we wanted to stay pure SQL. No custom DSL, no YAML, no config files describing your tables. Just .sql files. But we also wanted the freedom you get with code based declaration, so you don't need to worry about the order of statements in your declarative schema. You can split and organize your files however makes sense to you, pg-delta will figure out the right execution order. If your users table references a type defined in another file, that's fine. Just write your schema the way you want it organized.

If you don't have a declarative schema yet, the CLI will guide you through the setup. It asks where to generate from (local database or a custom URL), exports your schema into SQL files under supabase/database/, and you're ready to go:

$ supabase db schema declarative sync
No declarative schema found. Generate a new one ? [Y/n]
Generate declarative schema from:
>  1. Local database [generate from local Postgres]
2. Custom database URL [enter a connection string]
Reset local database to match migrations first? (local data will be lost) [y/N] y
Creating shadow database...
Applying declarative schemas via pg-delta...
Applied 21 statements in 1 round(s).
Declarative schema written to supabase/database
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...
Applying migration 20260320160742_init.sql...
Applying migration 20260410150534_disable_pg_net.sql...
No schema changes found

From there, the SQL files in supabase/database/ are your source of truth. You edit them directly, for example adding a column to a table, and run sync again:

$ supabase db schema declarative sync
Creating shadow database...
Applying declarative schemas via pg-delta...
Applied 21 statements in 1 round(s).
Generated migration SQL:
ALTER TABLE public.projects ADD COLUMN deleted_at timestamp without time zone;

Enter a name for this migration (press Enter to keep 'declarative_sync'): add_deleted_at_to_projects
Created new migration at supabase/migrations/20260413181801_add_deleted_at_to_projects.sql
Apply this migration to local database? [Y/n]
Connecting to local database...
Applying migration 20260413181801_add_deleted_at_to_projects.sql...
Migration applied successfully.

The full workflow is: edit your schema files and run sync. The CLI will create a migration and ask you to apply it.

If your changes include destructive statements, the CLI will warn you before applyin g:

$ supabase db schema declarative sync
Creating shadow database...
Initialising schema...
Seeding globals from roles.sql...
Applying migration 20260320160742_init.sql...
Applying migration 20260410150534_disable_pg_net.sql...
Applying migration 20260413181801_add_deleted_at_to_projects.sql...
Generated migration SQL:
ALTER TABLE public.projects DROP COLUMN deleted_at;

Enter a name for this migration (press Enter to keep 'declarative_sync'): drop_deleted_at
Created new migration at supabase/migrations/20260413182237_drop_deleted_at.sql
Found drop statements in schema diff. Please double check if these are expected:
ALTER TABLE public.projects DROP COLUMN deleted_at
Apply this migration to local database? [Y/n]
Connecting to local database...
Applying migration 20260413182237_drop_deleted_at.sql...
Migration applied successfully.

It also uses catalog caching so subsequent runs don't redo all the shadow-database work.

You can also skip all the interactive prompts with flags, which is useful for CI or agentic use:

supabase db schema declarative sync --apply --name add_back_deleted_at

How to enable it

Add this to your config.toml:

[experimental.pgdelta]
enabled = true

Or just pass --experimental on any of the declarative commands.

The declarative schema path defaults to database/ in your project root but you can change it:

[experimental.pgdelta]
enabled = true
declarative_schema_path = "my-schema/"

What we want to know

This is experimental and we want to shape it based on real usage. Some things we're curious about:

Does the edit > sync loop work for you? Or do you need something different?

What's missing? Any Postgres objects or patterns that pg-delta doesn't handle well?

How does it compare to whatever diffing tools you've been using (migra, pgAdmin, Atlas, pgroll, etc.)?

Debugging: when something goes wrong, the CLI generates a debug bundle you can attach to issues. Is that helpful? What else would make debugging easier?

What's next

To be clear: this is alpha. Even if pg-delta cover a lot of Postgres object type it isn't battle tested yet, and you will probably run into cases where the diff is wrong or incomplete. That's expected at this stage and exactly why we're putting it out now, we need real world usage to find the gaps.

We're actively improving pg-delta coverage and the declarative workflow. Goal is to make this the default diffing engine and eventually move the declarative commands out of experimental. What you tell us here directly affects what we work on next.

Links

pg-toolbelt repo (pg-delta + pg-topo)

CLI PR: Declarative sync command

CLI PR: Default folder rename to database/

Give it a try and let us know what you think. File issues on pg-toolbelt for diffing bugs and on cli for workflow stuff. Or just drop your thoughts here.

Original source

Multigres Operator is now open source

The Multigres Operator is now open source, with direct pod management, zero-downtime rolling upgrades, pgBackRest PITR backups, and OTel tracing.

GitHub integration on all plans

GitHub integration is now available on all plans. Connect your repo on the free tier to deploy migrations from your main branch via CI/CD, no branching required.

Supabase joins the Stripe Projects developer preview

Supabase is a co-design partner in Stripe Projects, a new CLI tool that provisions and connects services like Supabase, Vercel, and Clerk from your terminal, with credentials synced to your .env automatically.

Supabase docs over SSH

Browse all Supabase docs with standard Unix tools, or pipe them directly into Claude Code:
ssh supabase.sh setup | claude.

Supabase Security Newsletter

Subscribe to the Supabase security newsletter, sent only when there are important security updates.

Quick Product Announcements

Studio now has "Fix with Assistant" buttons across touchpoints, with a dropdown to send the prompt to Claude or ChatGPT.

Browser tabs now show your exact navigation path so you can tell your tabs apart at a glance.

Supabase secret keys now have Push Protection on GitHub, blocking accidental commits before they land.

Schema Visualiser: relation lines are now clickable, tables and columns have context actions, and popovers appear between connected tables.

Made with Supabase

Menugo - AI-powered QR code menu generator for restaurants

Gasindex - AI voice agents call thousands of businesses to track real-time gas prices in America, with Vision AI and crowdsourced submissions keeping data fresh

Guinndex - AI voice agents call thousands of businesses to track real-time Guinness prices in Ireland with Vision AI and crowdsourced submissions keeping data fresh

Festie - The unofficial Coachella 2026 companion

burn0 - Track Supabase costs per-request in real time

Community Highlights

I Dare You to Fact-Check Me: You Need Supabase Before You Build Anything Else with AI

Supabase in Production: What I Actually Learned Building Real Features

I Got Surprised By A GitHub Actions Quota. Built A Tool To Make Sure It Never Happens Again

The Solo Dev Cheat Code: Building Fast with Next.js, Supabase, and Vercel in 2026

Original source

What gets rate-limited?

Rate limiting applies to outbound fetch() calls made by your Edge Functions to other Edge Functions within your project. This includes:

• Direct recursion: A function calling itself
• Function chaining: Function A calling Function B
• Circular calls: Function A calling Function B, which calls Function A
• Fan-out patterns: A function calling multiple other functions concurrently

NOTE: Inbound requests to your Edge Functions and requests to external APIs (e.g., Stripe, OpenAI) are not subject to this rate limit. Only outbound calls from one Edge Function to another Edge Function are counted.

Rate limit budget

Each request chain has a minimum budget of 5,000 requests per minute. In busier regions, this budget may be higher. All function-to-function calls within the same request chain share this budget.

Why was this introduced now?

Over the last few weeks, we observed increased response times for Edge Functions across multiple regions. Upon analysing traffic, we noticed that a small number of projects that do recursive/nested function calls are adding significant strain on our servers. In particular, the incident we had on Feb 28th was caused by recursive function calls. We had to put this in as a safeguard to ensure reasonable performance for all projects hosted on the platform.

Based on our metrics, the rate limit has so far affected only 0.4% of projects. If you were affected, we apologize for the inconvenience.

How can you avoid being rate-limited?

It's still possible to follow recursive/nested patterns within the rate-limit. We've published a guide that provides several examples of how you can avoid rate limits.

Please contact support if you have any further questions about these rate limits.

Original source

Here’s everything that happened with Supabase in the last month:

Webinar: Ship Fast, Stay Safe

Learn how top agencies balance velocity with control when using AI coding tools to build production applications on Supabase.

Register

Logs Drains on Pro

Log Drains are now available on Pro. Send your Postgres, Auth, Storage, Edge Functions, and Realtime logs to Datadog, Grafana Loki, Sentry, Axiom, S3, or your own endpoint.

Blog Post

Docs now export to Markdown for AI tools

Every guide on

docs.supabase.com

now has a "Copy as Markdown" option, plus direct links to ask ChatGPT and Claude. Copy any page into your agent or tool of choice with one click.

Docs

Storage: major performance and security overhaul

Object listing is up to 14.8x faster on 60M+ row datasets. The prefixes table and its 6 triggers are gone, replaced with a hybrid skip-scan algorithm and cursor-based pagination. Security fixes close a path traversal vulnerability and prevent orphan objects from direct SQL deletes.

Blog Post

Edge Functions dashboard for self-hosted and CLI

List and search your functions, view details, test directly from the dashboard, and download as

.zip

. No longer cloud-only.

Twitter

Multigres Postgres parser: 2.5x faster than the cgo alternative

Built in 8 weeks using Claude Code. A comparable MySQL parser took over a year.

Blog Post

Twitter

Quick Product Announcements

⚠️ Action Required: OpenAPI spec access via anon key deprecated March 11. The

/rest/v1/

schema endpoint will only be accessible via service role or secret API keys after this date. Existing data API usage is unaffected.

GitHub

Observability Overview page is rolling out.

Twitter

Table filters now use AI. Describe what you want to find and the dashboard applies the right Postgres filters. Available under Feature Previews.

Twitter

Queue table operations in the Table Editor. Stage inserts, edits, and deletes, review in Diff View, then commit with

cmd + s

.

Twitter

Supabase plugin for Cursor is live.

Twitter

Copy AI prompts from the dashboard. The same prompts powering the Supabase AI Assistant are now exportable for use in your local agent or tool of choice.

Twitter

Inline SQL Editor saves SQL Snippets. Create and update snippets from Studio. Share via git in the

supabase/snippets

folder.

GitHub

Command Menu gets Create and Search shortcuts. Hit

cmd + k

to create tables, RLS policies, Edge Functions, and Storage buckets — or jump directly to an existing one.

Twitter

Read replicas now managed from the database replication page. Rolling out gradually — if you manage read replicas, look in Database settings.

Receipt downloads now available. Download receipts from the Invoices section in your org billing page.

Made with Supabase

A purpose-built tool for running powerful affiliate and referral campaigns.

Website

Supabase x YCombinator Hackathon winner: An AI Agent Personal Trainer

Website

AI video production for professionals

Website

Generate APA citation-ready references from a URL or DOI in seconds

Website

SupaClaw - A basic version of OpenClaw but built entirely on Supabase built-in features

GitHub

Community Highlights

Supabase is sponsoring Postgres Conference 2026. Deepthi and Sugu are speaking on Multigres: horizontal scalability and intelligent sharding for Postgres. April 21-23 in San Jose. Use code

2026_SUPABASE20

for 20% off.

Register

Codepup AI launched Supabase integration. Build a complete web app with a real Supabase backend — auto-generated, tested, and fixed by AI in under 30 minutes.

Blog Post

BKND joins Supabase. Dennis Senn, creator of BKND, is joining to build a Lite offering for agentic workloads. BKND stays open source.

Blog Post

Hydra joins Supabase. Joe Sciarrino, co-creator of Hydra, is joining to build Supabase Warehouse: an open data warehouse architecture for developers. Hydra co-developed

pg_duckdb

, which accelerates analytics queries on Postgres by over 600x.

Blog Post

Getting Started with Supabase - Official Guide

YouTube

Supabase on Observable Flutter - Episode

YouTube

Inside Supabase Edge Functions: How Serverless Magic Actually Works

Blog

Unlocking Scalable Backend Development: Why Supabase and Node.js are Revolutionizing Modern Applications in 2026

Blog

Adding GitHub, Google, and X Login to Next.js 15 with Supabase Auth

Blog

Original source

What’s Changing?

The Data API returns the full OpenAPI spec for any schema exposed to the Data API at the root path:
https://[projectref].supabase.co/rest/v1/

Starting March 11, we will begin deprecating support for accessing this endpoint via the anon key. You will get the following error message if this endpoint is accessed via the anon key

{"message":"Access to schema is forbidden","hint":"Accessing the schema via the Data API is only allowed using a secret API key."}

The endpoint remains accessible and the behaviour doesn't change if you are using the service role keys or the new secret API keys.

This does not affect normal Data API usage. Accessing data via
/rest/v1/your_table
or any client library will continue to work exactly as they do today.

Why?

Today, the endpoint returns schema details (tables, columns, and types of an exposed schema) to anyone with the anon key. While this does not expose actual row data, it provides more information about your schema than most production applications need.

As part of an ongoing effort to tighten default security across Supabase, we are removing this exposure. In practice, the schema spec is mostly useful during development, where you can use the service_role key. There are few cases where you would need it client-side in production (less than 0.1% of our projects have made a request to this endpoint using the anon key in the last 24 hours), and we do not think supporting those use cases is worth the security tradeoff.

Am I Affected?

You are affected if your app currently uses the anon key to fetch the Swagger spec.
You can check by reviewing requests to the /rest/v1/ endpoint via this log query.
If you see requests:

• Click into the event.
• Check whether the request is coming from the anon role.

What Should I Do?

• Check your logs. Use the log query above to see if any of your application traffic relies on this endpoint with the anon key.
• Move affected calls server-side If your application fetches the schema spec, move that call to a server-side context like Edge Functions where you can safely use the service_role or the new secret API keys.

Rollout and Communications Timeline

Date Change

• 17 Feb Changelog published
• 4 March Change announced in monthly newsletter
• 6 March Email notification to customers observed using this endpoint
• 11 March Newly created projects cannot access endpoint with anon key
• 24 March Final email notification to customers observed using this endpoint
• 8 April All existing projects cannot access endpoint with anon key

We may push these dates back based on customer feedback, but we will not move them forward.

What’s Next?

This is the first in a series of changes we are making to tighten default security settings across Supabase. Stay tuned for improvements to RLS usability, default table grants, and additional security features.

Original source