Changelog

Connect to your database using a temporary access token#

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:

Direct access:

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

Starting with pg_graphql 1.6.0 (shipping in new Supabase projects from 2026-06-15), GraphQL introspection is disabled by default.

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:

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:

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

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

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:

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:

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:

Rollout#