September 2026 Summaries

Trigger.dev migrated its active workloads and 1.23TB control-plane data from a 56TB AWS Aurora PostgreSQL cluster to PlanetScale while leaving nearly 55TB of mostly historical run data on Aurora, enabling a required PostgreSQL upgrade without broad application downtime. Because its durable execution platform processes roughly 250GB of data daily and supports jobs ranging from seconds to months, the company introduced routable run IDs so new runs could use PlanetScale while legacy runs remained accessible on Aurora, deployed PgBouncer to redirect connections with minimal interruption, and moved customers incrementally before making PlanetScale the default for new runs. The live control-plane migration required patches to pgcopydb to improve replication throughput, and an initial cutover failed after existing PgBouncer connections retained an Aurora username rejected by PlanetScale, producing 105 seconds of errors before an automated rollback restored service. After recopying the target data and correcting the pooler configuration, a second cutover succeeded, and Aurora was upgraded before the deadline; its reboot affected requests for old runs for about 90 seconds, while new runs and control-plane services continued operating. The experience highlighted the importance of testing persistent connections during rehearsals, and Trigger.dev plans further storage partitioning for active and completed runs.