Supabase · source page ↗ · last checked —

Change history

• Deprecation May 25, 2026, 7:31 AM

  Breaking change in pg_graphql 1.6.0 — GraphQL introspection disabled by default

  Edit 2026-06-13: Rollout date pushed from 2026-06-15 to 2026-06-29 to allow additional AMI build verification. No other changes to the rollout plan. Starting with pg_graphql 1.6.0 (shipping in new Supabase projects from 2026-06-29), GraphQL introspection is disabled by default. Who is affected New projects created on or after 2026-06-29 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.

• Deprecation May 18, 2026, 6:37 PM

  Self-hosted Supabase: switching Studio from supabase_admin to postgres (breaking change)

  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-cr

• Deprecation May 18, 2026, 6:31 PM

  Self-hosted Supabase: upgrading from PG 15 to 17 (breaking change)

  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

• Deprecation May 12, 2026, 1:23 PM

  Deprecation Notice: Support for Postgres 14 ending on 1st July 2026

  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. Dep

• Deprecation May 8, 2026, 11:32 AM

  Deprecation Notice: Dropping Support for Node.js 20

  As part of our ongoing commitment to providing a secure and reliable experience for all developers, we will drop support for Node.js 20 in accordance with our Support Policy. Affected libraries All packages published from the supabase-js monorepo: @supabase/supabase-js @supabase/auth-js @supabase/realtime-js @supabase/functions-js @supabase/storage-js @supabase/postgrest-js Timeline End of Support for Node.js 20: June 30, 2026 Why? Node.js 20 reached its official end of life on April 30, 2026 (a

• Deprecation May 1, 2026, 6:36 PM

  Breaking Change: OAuth token endpoint will return HTTP 200 instead of 201

  What's changing The /v1/oauth/token endpoint currently returns HTTP 201 Created on success. On May 26, 2026 June 1, 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 implement

• Deprecation Apr 28, 2026, 3:37 PM

  Breaking Change: Tables not exposed to Data and GraphQL API automatically

  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 starts to become the default for all new projects. This will

• Deprecation Feb 17, 2026, 1:40 PM

  Breaking Change: Removing access to OpenAPI spec via the anon key

  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 acc

• Deprecation Jan 26, 2026, 8:39 PM

  Breaking Change: pg_graphql no longer enabled automatically (within approx 3 weeks from today)

  In a forthcoming release within approximately 3 weeks, pg_graphql will be disabled by default on new Supabase projects. This change aligns pg_graphql with our security-first approach of minimizing exposed API surface area by default. Services and extensions that expose schema metadata are now opt-in rather than opt-out, reducing the default attack surface for new projects. Who is affected: New projects will no longer have pg_graphql enabled automatically Existing projects older than 30 days with