Studio 2025.10.09-sha-433e578 breaks SQL queries in self-hosted deployments - Zod validation error on formattedError

[actraiser]

Bug description

After updating Studio from 2025.10.01-sha-8460121 to 2025.10.09-sha-433e578 in a self-hosted Supabase deployment, all SQL queries in the Studio SQL Editor fail with a ZOD validation error. This is not restricted to SQL Editor but to any query, e.g. the tables can not be listed anymore etc.

Expected behavior

SQL queries should execute successfully and return results, as they did in Studio version 2025.10.01-sha-8460121.

Actual behavior

All SQL queries (e.g., SELECT * FROM boards;) fail with the following error in the network response:

  [
    {
      "expected": "string",
      "code": "invalid_type",
      "path": [
        "formattedError"
      ],
      "message": "Invalid input: expected string, received undefined"
    }
  ]

Steps to reproduce

1. Run self-hosted Supabase using Docker Compose
2. Update Studio image from supabase/studio:2025.10.01-sha-8460121 to supabase/studio:2025.10.09-sha-433e578
3. Restart Studio container
4. Open SQL Editor in Studio
5. Execute any SQL query (e.g. the default one:

select * from
  (select version()) as version,
  (select current_setting('server_version_num')) as version_number;

6. Observe error in browser network tab as well as the result window in the Studio SQL Editor

Environment

• Deployment method: Self-hosted Docker Compose
• Studio version (broken): supabase/studio:2025.10.09-sha-433e578
• Studio version (working): supabase/studio:2025.10.01-sha-8460121
• postgres-meta version: v0.91.7
• PostgreSQL version: 17.6.1.017
• Other service versions: All updated to match local Supabase CLI 2.51.0 docker container versions

postgres-meta container logs

When queries fail, postgres-meta shows DNS resolution errors:

{"level":"error","time":"2025-10-16T12:39:32.615Z","pid":1,"hostname":"13ebe5d3de34","reqId":"req-53","error":{"code":"EAI_AGAIN","message":"getaddrinfo EAI_AGAIN
db"},"request":{"method":"POST","url":"/query","pg":"db","opt":""}}
{"level":"error","time":"2025-10-16T12:39:32.628Z","pid":1,"hostname":"13ebe5d3de34","reqId":"req-54","error":{"code":"EAI_AGAIN","message":"getaddrinfo EAI_AGAIN
db"},"request":{"method":"POST","url":"/query","pg":"db","opt":""}}

Docker Container Versions installed on self-hosted version (same as what supabase cli installs):

supabase/postgres:17.6.1.017
supabase/studio:2025.10.01-sha-8460121 (after downgrade)
supabase/postgres-meta:v0.91.7
supabase/edge-runtime:v1.69.12
supabase/storage-api:v1.28.1
supabase/postgrest:v13.0.7
supabase/realtime:v2.53.2
supabase/gotrue:v2.180.0
supabase/kong:2.8.1
supabase/supavisor:2.7.3
supabase/logflare:1.4.0

Workaround

Downgraded Studio to the previous working version image: "supabase/studio:2025.10.01-sha-8460121" - no more ZOD errors on each query.

[Ednn0nd1au]

same error here

[cpedia]

same error here

[gowtham418p-rgb]

Downgraded Studio to the previous working version image: "supabase/studio:2025.10.01-sha-8460121" - no more ZOD errors on each query.

above worked for me, Thanks a lot

[actraiser]

Ok, i found the problem and fixed it. In your docker-compose file you use for self-hosting on production add the environment variables in the 'supabase-studio'-service:

 - "POSTGRES_HOST=${POSTGRES_HOSTNAME:-supabase-db}"
 - "CURRENT_CLI_VERSION=2.53.6"

It seems that "POSTGRES_HOST" has been introduced recently and if not set, supabaes uses just 'db' as hostname which of course will fail to fetch any data. The CURRENT_CLI_VERSION variable's purpose is to show update notifications if there is a newer version available and should be set to the latest version which is 2.53.6 as of today.

I updated to the supabase/studio:2025.10.20-sha-5005fc6 version with the two new variables and everything works now. Also no errors any more in the supabase-meta container.

[philogicae]

Ok, i found the problem and fixed it. In your docker-compose file you use for self-hosting on production add the environment variables in the 'supabase-studio'-service:

 - "POSTGRES_HOST=${POSTGRES_HOSTNAME:-supabase-db}"
 - "CURRENT_CLI_VERSION=2.53.6"

It seems that "POSTGRES_HOST" has been introduced recently and if not set, supabaes uses just 'db' as hostname which of course will fail to fetch any data. The CURRENT_CLI_VERSION variable's purpose is to show update notifications if there is a newer version available and should be set to the latest version which is 2.53.6 as of today.

I updated to the supabase/studio:2025.10.20-sha-5005fc6 version with the two new variables and everything works now. Also no errors any more in the supabase-meta container.

When using a custom DB port (my case), it still uses 5432, so this variable is also needed:

POSTGRES_PORT: ${POSTGRES_PORT:-5432}

After those changes, all good!

[happydebugcow]

Is it possible to set postgres user aswell? I have tried to set both POSTGRES_USER and DB_USER but still studio tries to connect to postgres user "postgres". my postgres user is called "app", so I need to override this, but setting those envs dont seem to work.

using the previous working image works, but not for the new image.

[AntonOfTheWoods]

@happydebugcow apps/studio/lib/api/self-hosted/constants.ts

export const ENCRYPTION_KEY = process.env.PG_META_CRYPTO_KEY || 'SAMPLE_KEY'
export const POSTGRES_PORT = process.env.POSTGRES_PORT || 5432
export const POSTGRES_HOST = process.env.POSTGRES_HOST || 'db'
export const POSTGRES_DATABASE = process.env.POSTGRES_DB || 'postgres'
export const POSTGRES_PASSWORD = process.env.POSTGRES_PASSWORD || 'postgres'
export const POSTGRES_USER_READ_WRITE = 'supabase_admin'
export const POSTGRES_USER_READ_ONLY = 'supabase_read_only_user'

Setting all of these appears to improve the situation considerably.

[singh-inder]

Hey everyone, I tested this locally using the same image versions mentioned above and wasn't able to reproduce the issue. The containers started up correctly and the services were reachable without adding any additional env vars. If you're still running into the issue, please share your docker-compose file. Happy to test again if you can provide a reproducible setup.