Error reference
Supabase & Postgres errors
The errors that actually show up when you migrate a database — what each one means, why it happens, and the exact SQL that fixes it.
auth
connection
- connect ENETUNREACH 2600:1f1c:…:5432ENETUNREACH ("network is unreachable") on a 2600:1f1c:… address means your client resolved the direct db.<ref>.supabase.co host to its IPv6 address but has no IPv6 route. The direct host is IPv6-only; IPv4-only CI runners, serverless functions, and Edge runtimes can't reach it. Connect through the Supavisor pooler host instead, which is IPv4-compatible.
- password authentication failed for user "postgres"This Postgres error (SQLSTATE 28P01) means the server rejected your credentials before opening the connection. On Supabase it is almost always a wrong DB password, the wrong username on the pooler host (it must be postgres.<project-ref>, not postgres), or a password with special characters that was not URL-encoded in the connection URI.
- remaining connection slots are reserved for non-replication superuser connectionsPostgres refused a new connection because the server is at or near its max_connections limit and the last free slots are held back for superuser use. Each connection is a separate backend process, so a migration that opens many direct connections (or leaks them) exhausts the pool fast. Route through the transaction-mode pooler on port 6543 and cap your client pool.
data
schema
- column "user_id" does not existPostgres raises SQLSTATE 42703 when a query references a column name that is not present on the target table in the current search_path. During a migration this usually means the column was not created yet, you are pointed at the wrong schema, or a camelCase name like "userId" was created quoted but referenced unquoted, so Postgres folded it to lowercase and looked for a column that does not exist.
- relation "profiles" already existsPostgres raises "relation ... already exists" (SQLSTATE 42P07) when a CREATE TABLE, CREATE INDEX, CREATE VIEW, or CREATE SEQUENCE targets a name that already exists in the target schema. During a migration this almost always means a non-idempotent DDL statement ran twice — a retried step, or an object the dashboard/an earlier partial run already created. Fix it by using CREATE ... IF NOT EXISTS, or by dropping the pre-existing object if you intend to recreate it.
- relation "public.events" does not existPostgres raises "relation … does not exist" when a query references a table, view, or sequence that isn't visible on the current search_path — usually because it lives in another schema, hasn't been created yet, or the migration ran statements in the wrong order.
- type "public.user_role" does not existPostgres raises this when a statement references an enum or composite type that has not been created yet — usually a CREATE TABLE with an enum column that a later CREATE TYPE would have defined. The fix is to run CREATE TYPE before the CREATE TABLE that uses it. SQLSTATE is 42704 (undefined_object).
storage