Cases3 cases

1 to 3 of 3

1. IL-0369 Railway's backend API went down when a column migration waited on locks and replicas could not get database connections

   Railway2025

   Symptoms

   At 15:18 UTC on 9 December 2025, Railway's backend replicas became unhealthy and stopped serving traffic. Dashboard access, CLI operations, logins, the API and the processing of GitHub-based deployments were disrupted, while running deployments stayed online.

   Probe failuresLock contention or deadlockDatabase overloadService outage

   Trigger

   Engineers merged a database schema change with a data migration at 15:03 UTC, and the migration began applying at 15:17 UTC. It added a nullable column to a heavily used table of about 1 billion rows.

   Root cause

   Faulty deployment

   Component

   DatabaseDatabase proxy and connection poolerSchema migrationLiveness and readiness probes

   Contributing factor

   Health check tied to a dependency

   Action items

   • Increase database connections and reconfigure PgBouncer to work within those limits
   • Fix the long-running query so it no longer causes row lock issues

   View case
2. IL-0315 Railway's backend API went down when an index build locked a billion-row Postgres table and used up every connection

   Railway2025

   Symptoms

   At 18:36 UTC on 28 October 2025, two minutes after a database change went live in production, Railway's internal monitoring alerted and paged the engineering team. The dashboard could not be opened, CLI operations that use the API, such as railway up, failed, GitHub-based deployments were delayed because webhook processing failed, and all Railway Public API operations were disrupted.

   Service outageLock contention or deadlockDatabase overload

   Trigger

   A routine schema change to the backend's Postgres database, introduced at 18:23 UTC and live in production at 18:34 UTC, that added a new column with an index without the CONCURRENTLY option.

   Root cause

   Faulty deployment

   Component

   DatabaseDatabase proxy and connection pooler

   Contributing factor

   No configuration testsLimited debug access

   Detection

   Internal monitoring alerts paged the engineering team at 18:36 UTC, and the incident was declared at 18:41 UTC.

   Remediation

   • The index migration finished after about 30 minutes and released the table lock, and the queued operations and connection pools recovered

   Action items

   • Enforce CONCURRENTLY for all index creation in CI and block pull requests that do not use it
   • Adjust PgBouncer pool limits so they cannot overwhelm the Postgres instance's capacity
   • Configure database user connection limits so administrative access stays possible during incidents

   View case
3. IL-0307 Supabase's Postgres connection pooler Supavisor 2.0 dropped connections for about 80% of us-east-1 tenants

   Supabase2025

   Symptoms

   At 16:05 UTC on January 29, 2025, most clients connected through Supavisor, Supabase's Postgres connection pooler, in us-east-1 were disconnected and could not reconnect reliably. Connections dropped for about 80% of tenants, and Supabase Storage connectivity also failed until the pooler was fixed.

   Connection resetsIntermittent connection failures

   Trigger

   The planned upgrade of Supavisor to version 2.0 in us-east-1, which completed at 14:46 UTC.

   Root cause

   Faulty deployment

   Component

   Database proxy and connection poolerDatabase

   Contributing factor

   –

   Remediation

   • Rolled Supavisor back to the previous version

   Action items

   • Cut rollback time from 40 minutes to under 90 seconds
   • Detect client disconnections within 2 minutes

   Lessons

   Rollback was too slow and the pooler was not resilient enough to unforeseen failures under load; future work focuses on faster rollbacks to reduce the impact of similar failed deployments.

   View case

By root cause1