Database Query Error Rate %, Supabase

​

At a glance

This gauge reports the share of SQL statements that failed against your Supabase Postgres database in the window. A query “fails” when Postgres returns an error rather than a result set: a constraint violation, a deadlock abort, a permission denial, a syntax error, a statement timeout, or a connection that could not be served. It is the database-level health signal beneath the API: where PostgREST 5xx Error Rate % tells you the API returned an error to a client, this tells you the query itself errored inside Postgres, which is often the root cause one layer down. For a platform or SRE team this is a primary alert gauge. A query error rate creeping above 1% means a meaningful fraction of database work is being rejected, and users are seeing failures right now.

​

Calculation

error_rate = failed_statements / (failed_statements + successful_statements)
fire when: error_rate > 1% (sustained over the 5m window)

1. Not every rollback is a fault. Some applications use ROLLBACK deliberately (optimistic-concurrency retries, transactions that test a condition and back out, advisory-lock probes). A low baseline rollback rate is normal and benign. The alert threshold sits at 1% precisely so routine, intentional rollbacks stay below it and only genuine error surges trip it. The error-log breakdown by SQLSTATE is what separates “expected rollback” from “real failure”.
2. The error class names the cause. SQLSTATE codes group the failures: class 23 (integrity constraint violation) means duplicate keys or foreign-key breaks, often a bad write path; class 40 (transaction rollback) includes 40P01 deadlocks and serialisation failures, meaning contention; class 42 (syntax / access rule) means a broken query or a missing column, usually a bad deploy; class 53 (insufficient resources) and 57 (operator intervention) include out-of-memory, disk-full, and statement-timeout cancellations, meaning capacity. Reading the dominant class tells you which sibling card to open next.

​

Worked example

1. The error class changed, not just the volume. At baseline the few failures were 40001 (serialisation failures, normal under optimistic concurrency). At peak the dominant class is 40P01, deadlocks. The cause is not “more of the same”; a new contention pattern has appeared under load.
2. Deadlocks confirm it. Cross-referencing Deadlocks (last 5m), the deadlock count has jumped from 0 to dozens in the window. Two transactions are grabbing the same rows (seat-inventory rows for the hot event) in opposite orders, so under concurrency they lock each other out and Postgres aborts one to break the cycle. Each abort is a failed statement, which is what is driving the gauge.
3. It is user-facing right now. PostgREST 5xx Error Rate % has risen in step: the aborted transactions bubble up as failed API calls, so buyers are seeing “could not reserve seat” errors at the worst possible moment. This is the database error becoming a lost sale.

Diagnose by error class (SQLSTATE):
  class 23  integrity violation   -> bad write path / duplicate or FK break
  class 40  rollback (40P01/40001)-> deadlock / serialisation contention
  class 42  syntax / undefined    -> broken query, missing column (bad deploy)
  class 53  insufficient resources-> disk full, out of memory (capacity)
  class 57  operator intervention -> statement timeout / cancel
  class 08  connection exception  -> pool exhausted / connection dropped

Find the deadlocking statements:
  -- from the Postgres error log, deadlock entries name both statements
  -- and the relation; then confirm the access pattern:
  SELECT query, calls, rows
  FROM pg_stat_statements
  WHERE query ILIKE '%seat_inventory%'
  ORDER BY calls DESC;

Fixes, by class:
  deadlock (40P01): make all writers lock rows in the SAME order;
                    or take a single SELECT ... FOR UPDATE on a parent row
                    to serialise access to the contended set.
  serialisation (40001): add bounded application-level retry with backoff.
  resources (53): check Database Disk Usage / Memory Usage and tier limits.
  syntax (42): roll back the offending deploy.

1. Read the error class, not just the rate. The same 1.74% means a different action depending on whether it is class 23 (bad writes), class 40 (contention), class 42 (bad deploy), or class 53 (capacity). The breakdown is the diagnosis.
2. A low baseline is normal; a spike with a changed class is the signal. Routine optimistic-concurrency rollbacks keep a small non-zero baseline. What matters is a jump in volume together with a shift in the dominant error class.
3. Database errors become lost revenue one layer up. A query error rate spike almost always shows up as an API 5xx spike and a user-facing failure. Pair this gauge with PostgREST 5xx Error Rate % to size the customer impact.

​

Sibling cards

​

Reconciling against the source

In the Supabase dashboard, open Logs → Postgres and filter to error-severity entries; each carries a SQLSTATE code, which gives you the same class breakdown the card uses. Reports → Database shows the rollback/commit trend behind the rate. Compute the rollback ratio directly: SELECT xact_commit, xact_rollback, round(100.0 * xact_rollback / nullif(xact_commit + xact_rollback, 0), 2) AS rollback_pct FROM pg_stat_database WHERE datname = current_database();. This is the lifetime ratio since reset, not the recent delta the card shows, and it counts all rollbacks (including intentional ones), so it reads higher than the error-log-filtered rate. Inspect specific failures: deadlock entries in the Postgres log name both statements and the relation; statement-timeout cancellations appear as 57014; constraint violations as class 23. The managed-service console exposes equivalent error and rollback charts under the project’s observability section; confirm the window and whether it counts statements or transactions before comparing.

​

Known limitations / FAQs

​

Tracked live in Vortex IQ Nerve Centre