Troubleshooting the database

#403 NO_POLICY_DEFINED or POLICY_DENY on a table

• Cause: No access policy allows this caller and the table's row-level security isn't forced (NO_POLICY_DEFINED), or a policy denies it (POLICY_DENY). App users get nothing until something allows them.
• Check: sov sim run --resource public.<table> or Simulation in the console shows which layer stopped the request for each kind of user.
• Fix: Add the policy or row-level security the table needs (Row-level security and access, Security recipes).
• Verify: Re-run the simulation; the user types you expect now pass and the others are still refused.

#A query returns no rows (or an update changes none), but the rows exist

• Cause: Row-level security filters rows silently: the caller may run the query, but no row matches its policy (for example user_id = auth.uid() for an anonymous caller).
• Check: Test the request for that kind of user in Simulation (it shows which policy filtered the rows), and read the table's policies.
• Fix: Correct the policy condition or the data it compares (owner columns filled with the user's id). See Auth helpers in SQL for auth.uid() and friends.
• Verify: Signed in as a test user, the query returns the rows you expect — and only those.

#408 "SQL statement timeout exceeded", or 400 "canceling statement due to statement timeout"

• Cause: The statement ran longer than the statement timeout — usually a missing index, a scan of a large table, or a lock held by another transaction.
• Check: Explain the query in the SQL editor and look for sequential scans on large tables. Observability › Query Performance lists the slowest statements (Performance).
• Fix: Add an index or a limit; move heavy work to a migration or a background function. Raise the timeout only for work that is slow by nature (Pooling and timeouts).
• Verify: Explain shows an index scan and the query finishes well under the timeout.

#A direct connection fails: SSL required, password authentication failed, or a timeout

• Cause: The client doesn't use TLS, the password was reset, the user or database name was typed by hand, or a firewall blocks outbound port 5432.
• Check: Compare with Connect › Database: host db.<org-id>.sovarias.in, port 5432, sslmode=require, your project's user and database.
• Fix: Copy the URI from Connect; reset the password there if it was lost (it is shown once). Allow outbound 5432 on your network.
• Verify: psql "<uri>" -c "select 1" succeeds.

#"too many connections" or clients waiting for a connection

• Cause: Many short-lived clients (serverless functions, edge runtimes) open direct connections, or the pool size is too small for the traffic.
• Check: Project settings › Database › Pooling & timeouts and the connection limit for your compute size.
• Fix: Use the pooled connection string (transaction mode) for serverless and functions; keep direct connections for migrations and long-lived servers (Database: connection, compute, disk and backups).
• Verify: Connection counts stay below the limit under load.

#A migration fails, or `sov db migrations push` stops

• Cause: An SQL error in the migration, data that breaks a new constraint, or a change already made by hand in the console.
• Check: Run sov db migrations push --dry-run: each pending migration runs in a transaction that is rolled back, so you see the error without changing anything.
• Fix: Fix the migration (or the data) and push again. A failed migration is not recorded as applied (Migrations).
• Verify: The dry run passes, then the real push lists the migration as applied.

#400 when app code runs `create`, `alter` or `drop`

• Cause: Schema changes from app code aren't allowed through the data API — they belong in migrations or the SQL editor.
• Check: Which key or session ran the statement.
• Fix: Make the change in a migration (Migrations) or in the SQL editor as a team member.
• Verify: The migration appears in the project's migration history.

Postgres error codes (23505, 23503, 42501, …) and what they mean: Postgres in Sovaria.

#Still stuck?

Email outreach@sovaria.in with your project URL, the time it happened (with time zone), the X-Request-ID response header or the trace_id from the error body, and the failing SQL with any personal data removed. Never send keys, passwords, tokens or your users' data.