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#

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:

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

   _10

   sh utils/reassign-owner.sh

   
   
2. 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)
3. Restart the stack
4. 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#

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

1. Pulls the Postgres 17 binaries and upgrade scripts
2. Stops the Supabase stack
3. Disables incompatible extensions and runs pg_upgrade in a temporary PG 15 container
4. Re-enables extensions, applies patches, and runs VACUUM ANALYZE in a temporary PG 17 container
5. Swaps data directories (the original is kept as ./volumes/db/data.bak.pg15)
6. 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:

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#