Supabase Release Notes

We are changing the default value of the Postgres log_connections setting from on to off for new projects, and will be migrating all Free and Pro projects to the new default configuration. This reduces log volume and noise, and aligns with industry-standard defaults (RDS, GCP Cloud SQL also default to off). We will be exposing this configuration to all users via dashboard and API for better log management, with log_connnections and log_disconnections now available via the Update postgres config API route and will take effect from 9 July onwards.

Who's affected

• New projects (all tiers) created after 9 July will have log_connections=off by default.
• Existing Teams + Enterprise customers (including HIPAA add-on customers) - Configuration is unchanged
• Existing Free / Pro customers - log_connections will be turned off from 9 July. This configuration can be re-enabled below

How to re-enable

You can re-enable log_connections via the dashboard under Database > Settings. It can also be re-enabled programmatically via the Management API via the Update postgres config API route. Changes will only take effect from 9 July onwards.

Learn more about PostgreSQL logging settings in our logging documentation.

Original source

What's Changing?

The week of July 6, 2026, the default self-hosted Supabase configuration for API_EXTERNAL_URL will change to include the /auth/v1 path prefix:

• API_EXTERNAL_URL will default to http://localhost:8000/auth/v1 (previously http://localhost:8000)
• GOTRUE_JWT_ISSUER in docker-compose.yml will change to ${API_EXTERNAL_URL} (the actual URL will stay unchanged)
• OAuth redirect configuration placeholders in docker-compose.yml will become ${API_EXTERNAL_URL}/callback
• The API gateway routes for SAML SSO move from /sso/saml/* to /auth/v1/sso/saml/*, so SAML ACS and metadata endpoints become …/auth/v1/sso/saml/acs and …/auth/v1/sso/saml/metadata

This aligns self-hosted Supabase with the platform behavior, and the CLI .

Why?

• Consistency across deployments. API_EXTERNAL_URL behaves identically on platform, self-hosted, and CLI.
• Custom OAuth providers work out of the box. GoTrue builds custom-provider callback URLs as API_EXTERNAL_URL + /callback. With the prefix now in the base URL, that resolves to …/auth/v1/callback and matches the existing API gateway route.
• SAML aligns with the /auth/v1 convention used by every other auth endpoint, rather than living at a bare /sso/saml/* path.
• The docs become accurate. The guidance that "your callback URL is built from API_EXTERNAL_URL" is now literally true, instead of relying on the /auth/v1 prefix being manually prepended in the compose file.

Am I Affected?

You are affected if you run self-hosted Supabase from the ./docker directory and pull updates from master, and any of the following apply:

• You've overridden API_EXTERNAL_URL in your .env (e.g. https://my-domain.com ) - you'll need to change it to https://my-domain.com/auth/v1.
• You maintain a customized docker-compose.yml with OAuth providers - the redirect URIs change from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback to avoid a doubled /auth/v1 prefix.
• You use SAML SSO - your IdP points at the old /sso/saml/* endpoints and must be updated to /auth/v1/sso/saml/*. This is the main breaking case.

You are not affected if you:

• Use the Supabase platform
• Have OAuth providers registered with Google/GitHub/etc. - the final callback URL is unchanged (…/auth/v1/callback), so no re-registration in the provider's developer console is needed
• Don't use SAML SSO and pull the new docker-compose.yml and .env.example together without local changes - the defaults stay consistent

What Should I Do?

If you pull the updated docker-compose.yml and .env.example together with no customizations, no action is required unless you use SAML SSO.

If you've customized API_EXTERNAL_URL :

• Append /auth/v1 to your value (e.g. https://my-domain.com → https://my-domain.com/auth/v1 )
• If your override file sets OAuth redirect URIs, change them from ${API_EXTERNAL_URL}/auth/v1/callback to ${API_EXTERNAL_URL}/callback
• Restart the stack

If you use SAML SSO:

• Pull the updated docker-compose.yml (or update your Kong and Envoy routes to /auth/v1/sso/saml/acs and /auth/v1/sso/saml/metadata )
• Restart the stack
• Re-fetch your service provider metadata from {API_EXTERNAL_URL}/auth/v1/sso/saml/metadata and update your IdP (ACS URL, SP entity ID) with the new endpoints
• See the self-hosted SAML SSO guide

If you'd rather defer: keep your existing API_EXTERNAL_URL without the /auth/v1 suffix and retain your current OAuth/SAML configuration. This is a default change, not a removal - but we recommend aligning soon, since custom OAuth providers won't work without it.

Rollout

Date Change

2026-06-18 This changelog published

2026-07-06...10 Updated self-hosting OAuth and SAML SSO docs published

2026-07-06...10 Default change ships in the next self-hosted Supabase release

Original source

Realtime Broadcast can now send and receive binary payloads in addition to JSON. This lets you broadcast compact binary data without the overhead of JSON encoding.

Binary payloads are supported across every way you send a Broadcast message: the client libraries (over WebSocket), the REST API, and directly from your database.

When to use binary payloads

Binary shines whenever your data is numeric, high-frequency or densely packed. In these cases JSON's textual encoding adds significant overhead.

Sensor and telemetry streams. Connected devices emit steady streams of numeric readings. These can be temperature, accelerometer values, GPS coordinates, battery levels, etc. They can be packed into fixed-width binary fields, where a reading that takes 20–30 characters as JSON text fits in just a few bytes across thousands of devices.

Screenshot and presentation streaming. A presenter or support agent shares a live view by broadcasting periodic image frames (JPEG/PNG) to viewers. Each frame is transient and inherently binary, so there's no need for durable storage and no reason to pay the base64 tax. Just send the image bytes straight to everyone watching.

Usage

Client libraries (WebSocket)

Pass an ArrayBuffer / ArrayBufferView (Uint8Array for example) or the equivalent in non-JS SDKs as the payload.

REST API

Single-message endpoint where Content-Type selects application/json vs application/octet-stream. channel.httpSend() from JS.

Database

realtime.send_binary() with a bytea payload.

Minimum versions

WebSocket (supabase-js): 2.91.0

WebSocket (supabase-swift): 2.44.0

REST API through httpSend (supabase-js): 2.107.0

We are in the process of adding support to binary payloads across all SDKs.

⚠️ Binary payloads sent to clients on older SDK versions (or SDKs that don't support binary payloads) are silently dropped.

More information can generally be found in the Broadcast page of the Realtime guides.

Original source

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

Supabase Series F

Supabase has raised a $500M Series F at a $10B pre-money valuation. It’s led by GIC.

Multigres 0.1 alpha released

Multigres is a scalable operating system for Postgres: it holistically manages your Postgres instances and gives you sharding, connection pooling, automatic failover, and backup orchestration. Multigres v0.1 alpha is an open-source-only release. Multigres for Supabase is coming soon.

Passkey Sign-in for Supabase Auth

Users can now sign in with biometrics (Face ID, Touch ID, Windows Hello), a device PIN, or a hardware security key. Built on the WebAuthn standard, passkeys are passwordless and phishing-resistant. Supabase Auth stores only the public key for verification, while private key material stays on the user's device. Available to all projects in beta today.

Supabase is now an official ChatGPT app

Connect your Supabase projects to ChatGPT and manage your database infrastructure conversationally. The integration includes 29 tools covering SQL execution, schema changes, branching, edge function deployment, and live logs, all without leaving ChatGPT. Works on all Supabase plans with paid ChatGPT plans (Plus, Pro, Team, Enterprise).

Supabase Plugin for AI Coding Agents

A single install that gives your AI coding agent everything it needs to build on Supabase. The plugin bundles the Supabase MCP server and agent skills so your agent can query databases, manage migrations, deploy Edge Functions, and follow Supabase and Postgres best practices out of the box. Supports Claude Code, Cursor, Codex, and Gemini CLI.

Feature preview: Temporary token-based database access

Grant developers direct database access using Personal Access Tokens with; no passwords required. Project admins assign a specific database role and expiry window (up to 90 days) per user. Revoking project access immediately cuts database access too. Fully supported in branch projects, and available on Postgres 17+.

Quick Product Announcements

• Guide to securing your app against npm supply-chain attacks.
• Supabase client libraries now support traces following the W3C standard, compatible with any compliant tracing SDK including OpenTelemetry, Sentry, Datadog, and Honeycomb.
• The Schema Visualizer now supports editing tables directly on the page, making it easier to design your database while viewing the full picture.
• Long text columns can now be expanded in the sidebar to view full content, with support for rendering as Markdown.
• The RLS Tester lets you run queries as another user, see which RLS policy took effect, and test via client libraries with AI-assisted SQL conversion. Enable it from the feature previews section in the dashboard.
• Navigation keyboard shortcuts are available in the dashboard. Press cmd+k and open "Show all keyboard shortcuts" to see the full list.
• pg-delta is a new schema-diffing engine built from scratch at Supabase to handle the full range of Postgres objects, including tables, columns, RLS policies, functions, triggers, indexes, and extensions.
• Logs usage is now metered. Pro and Team plans include 5 GB ingest and 1,000 GB query per month, with overage at $0.50/GB and $0.002/GB, respectively. New organizations may move to the new pricing as early as June; existing organizations begin migrating July 1.
• Supabase is now available as a connector on Perplexity Computer. With Supabase as the persistent data layer, Computer can read from and write back to your Postgres tables, keeping state across runs without custom glue code.

Meet the Supabase team

• Webinar: From scattered tools to workflows that scale: Supabase + Perplexity Computer for Small Businesses. June 25 at 10:00 am PT.
• Webinar: From shipped app to production-ready insight with Supabase + Hex Agent. July 8 at 9:00am PT.
• Hangout with the Supabase team during Casual Wednesdays on Discord at 10:00 am PT.
• DASH by Datadog, June 9-10, New York
• Figma Config 2026, June 23-25, San Francisco
• Vercel Ship 26, June 30, New York

Made with Supabase

Join our Discord, showcase your app, and maybe you’ll get featured.

• Gather is a simple way to stay connected with your family, friends, and activity groups.
• 021 helps you make better product decisions with clarity, context, and conviction.
• Nover is the unified visual generation suite that gives designers pixel-perfect precision over every render.

Community Highlights

• supabase-py has crossed 1 million downloads per day on PyPI.
• A developer replaced two years of custom Okta token exchange logic with Supabase's custom OAuth/OIDC provider in 40 minutes.
• The Multigres team used TLA+ to find a silent data-loss bug in pg_rewind that can leave a standby carrying phantom writes after two rapid failovers. The proposed fix embeds a UUIDv7 in each timeline history entry to distinguish independent promotions.

Original source

For the past six months we've been tracking a steady increase in coordinated abuse of Supabase's free-tier email infrastructure. Bad actors were standing up free Supabase projects, rewriting the auth email templates with phishing content, and then triggering signup or password-reset flows against arbitrary email addresses to deliver those phishing emails from our SMTP infrastructure to people who had no relationship with Supabase.

We rolled out increasingly aggressive rate limits on outbound auth emails. We deployed keyword blocklists to catch the most common phishing payloads. We built automated detection that flagged suspicious template content and disabled offending projects. Each one was met with a workaround within days if not hours.

To our knowledge Supabase was the only auth provider that offers both a hosted email service and fully customizable email templates on free tier. Obviously this combination is what made us a uniquely attractive target.

All of this is to say we tried hard to ship changes that wouldn't affect legitimate users. But the abusive accounts 6 while likely just a handful of individuals 6 given the scale of their abuse, were responsible for the bulk of spam leaving our infrastructure, and we've reached the point where the volume risks having our email server blacklisted entirely.

What's changing

Starting today Wednesday, 3 June 2026, new free-tier projects using Supabase's default email provider will no longer be able to modify their auth email templates. The default templates 6 confirmation, password reset, magic link, etc. 6 will be used as-is.

Who's affected

Existing free-tier projects keep their current email templates exactly as they are. Nothing changes for projects created before 3 June 2026. Paid plans (Pro and above) are not affected. Template customization continues to work as it does today. Free-tier projects that configure their own SMTP provider can continue to customize templates freely. The restriction only applies when sending through Supabase's default SMTP. If you're starting a new free-tier project and need branded auth emails, you have two options that work today:

Configure your own SMTP provider (Resend, Postmark, SendGrid, Amazon SES, etc.) in your project's auth settings 6 once enabled, you can customize your templates as before.

Original source

We're excited to announce the beta release of Passkeys for Supabase Auth — a passwordless, phishing-resistant credential built on the WebAuthn standard.

With passkeys, users sign in with biometrics (Face ID, Touch ID, Windows Hello), a device PIN, or a hardware security key. Supabase Auth stores the public key needed for verification; private key material remains managed by the user’s authenticator or credential provider.

How does it work?

Each passkey enrollment or sign-in is a WebAuthn ceremony with three steps:

1. Options: the client requests a challenge from Supabase Auth.
2. Ceremony: the browser invokes navigator.credentials.create() (register) or navigator.credentials.get() (sign in), prompting the user to approve with biometrics or a security key.
3. Verify: the signed response is sent back to Supabase Auth, which validates the challenge and either stores the new credential or issues a session.

Supabase Auth uses discoverable credentials, so users don't need to type an email or username — the authenticator resolves the account from the credential it already stores.

Enable passkeys in the Dashboard

Open Authentication → Passkeys in the Dashboard, toggle on Enable Passkey authentication, and fill in your WebAuthn relying party details:

• Relying Party Display Name: human-readable name shown during the passkey prompt (e.g. "My App").
• Relying Party ID: your bare domain (e.g. example.com). No scheme, port, or path.
• Relying Party Origins: up to 5 allowed origins (e.g. https://example.com,https://app.example.com).

The Dashboard pre-fills these from your project's Site URL and project name.

Passkeys can also be configured via the CLI and the Management API.

Use it from your app

[!NOTE] The Passkeys API is currently experimental and requires an explicit opt-in as the API may change without notice during the beta phase.

Opt in to the experimental API when creating the client:

import { createClient } from '@supabase/supabase-js'
const supabase = createClient(supabaseUrl, supabasePublishableKey, {
  auth: {
    experimental: { passkey: true },
  },
})

Register a passkey for an authenticated user — typically from a security settings page or right after sign-up:

const { data, error } = await supabase.auth.registerPasskey()
// data: { id, friendly_name, created_at }

Sign in with a passkey — no email or phone needed upfront; the authenticator picks the account:

const { data, error } = await supabase.auth.signInWithPasskey()
// data.session and data.user are set; a SIGNED_IN event is dispatched

Manage passkeys — list, rename, and delete from the current user's account:

const { data: passkeys } = await supabase.auth.passkey.list()
await supabase.auth.passkey.update({
  passkeyId: passkeys[0].id,
  friendlyName: 'Work laptop',
})
await supabase.auth.passkey.delete({ passkeyId: passkeys[0].id })

What we'd like to know from you

• Any bugs or rough edges you hit during passkey registration or sign-in flows.
• Friction when configuring the relying-party settings in the Dashboard, CLI, or Management API.
• Feedback on integrating passkeys in native or mobile flows.
• Suggestions for improving the API ergonomics or documentation.

Drop your feedback in this thread or open an issue.

Related links

• Documentation: Passkey authentication
• Dashboard: Authentication → Passkeys
• JavaScript reference:
  • auth.registerPasskey
  • auth.signInWithPasskey
  • auth.passkey (two-step API)
  • auth.admin.passkey (server-side)

Original source

We are enabling an experimental feature that allows direct, temporary database access using user tokens, such as Personal Access Tokens (PATs).

This feature allows giving developers direct database access, as a specific role, without ever disclosing the database password.

Project administrators specify the database role a project user is allowed to access the database as, and the time period for which that access is valid. Because the credential (token) is tied directly to a specific user, it will be possible to see who accessed the database, and with which role. Revoking project access from a developer, immediately revokes their ability to log into the database.

This setting is only available to project owners and administrators.

Enabling the feature preview

Database users must be enabled through the feature preview:
https://supabase.com/dashboard/org/_/?featurePreviewModal=supabase-ui-jit-db-access

Configure access

By default, Temporary token-based access is disabled and must be enabled on a per project basis. In your project’s database settings, enable Temporary token-based access:
https://supabase.com/dashboard/project/_/database/settings

Once enabled, you can grant other team members access. This is managed through the Add rule button. Access control is fine grained per database role. A user can be granted access to one or more database roles. Expiry is tied directly to the role and can be scoped down to minutes or a maximum of 90 days.

Branches

Temporary access is fully supported in branch projects. When enabling temporary access on the main project, temporary access will also be enabled for all existing and future branches.

Users access can be scoped to branches only.

Temporary access is particularly helpful when dealing with branches, as you don’t need to know or modify any passwords, your Personal Access Token is sufficient for gaining access.

Disabling

Temporary token-based access can be disabled for all users at once through the settings screen. Users will regain their previous access if you re-enable Temporary token-based access. Individual user’s access can be controlled by modifying the rule for that specific user.

Connecting to the database with an Temporary token

Once granted access, users can access the database using their Personal Access Token (PAT). Access works through both the Shared Pooler and directly to the database. Users will only be able to access database roles for which they have been granted access.

Shared pooler:

psql "postgres://{role}.{database_ref}@aws-1-{region}.pooler.supabase.com:6543/postgres?sslmode=require&options=-c%20jit%3dtrue"

Direct access:

psql "postgres://{role}@db.{database_ref}.supabase.co:5432/postgres?sslmode=require"

Current limitations

This feature is only available to projects on Postgres 17+. Older Postgres versions are not, and will not, be supported.

Temporary token-based access requires a user to be a valid member of the project. At present it is not possible to give access to users that are not part of your project. We are working on adding support for non-project members to be invited. This will allow granting database access to an external contractor, for example, while not making them part of your Supabase project or organization.

Temporary token-based access is not available through the dedicated pooler (port 6543 on the database host).

Original source

Who is affected

• New projects created on or after 2026-06-15 will run pg_graphql 1.6.0+ and have introspection disabled by default.
• Existing projects are not affected unless and until you upgrade pg_graphql to 1.6.0+ (e.g. by upgrading your project's Postgres version). Older projects keep their current behaviour.

What's changing

Previously, __schema and __type queries worked without any configuration. From 1.6.0, they return an error unless you explicitly opt in:

{
  "errors": [{
    "message": "Unknown field \"__schema\" on type Query"
  }] }

If your project uses any of the following, you'll need to opt in before relying on introspection:

• Supabase Studio GraphQL explorer (GraphiQL) — uses introspection to display your schema and provide autocomplete
• External GraphiQL or GraphQL Playground
• Apollo DevTools
• Relay compiler
• Code generators (e.g. graphql-codegen)
• Any tool that calls __schema or __type directly

Regular data queries are not affected. accountCollection, insertIntoAccountCollection, etc. continue to work normally regardless of this setting.

How to opt in

Run this SQL once per schema you want to expose introspection on:

comment on schema public is e '@graphql({"introspection": true})';

If you already have a comment on your schema (e.g. for inflect_names), combine the keys:

comment on schema public is e '@graphql({"inflect_names": true, "introspection": true})';

Why this change

Introspection exposes your full API surface — all types, fields, and relationships — to anyone who can reach the endpoint. Disabling it by default reduces the risk of API enumeration and makes it easier to keep private schemas private.

Further reading

• Configuration docs — Introspection
• pg_graphql changelog

Original source

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