July 9, 2025
Goldsky case study
Replacing an outbox pattern with Sequin cut IOPS in half. This allowed Goldsky to downsize their infrastructure, saving thousands of dollars per month.
Background
Goldsky is a real-time blockchain indexing platform that runs critical infrastructure for Web3 companies like Zora, Base, and Polymarket. Their platform processes massive volumes of on-chain data and syncs it into Postgres to serve as a source of truth for APIs and downstream systems.
The outbox pattern and triggers were crushing the database
Goldsky relied on the outbox pattern. They used triggers to write to an “outbox” table in their Postgres database after inserts, updates, or deletes to core tables. A webhook delivery system (Hasura) picked up events from the outbox table for delivery to customer webhook endpoints. This approach worked, but came at a cost.
Every webhook delivery required three writes: the initial insert into the outbox table, an update to claim the row for delivery, and a delete after successful transmission. Failures were even more costly. If a customer’s webhook endpoint went down, this could mean a pile-up of failing messages in the outbox table. Each failed delivery meant another cycle of row updates.
This pattern generated enormous IOPS load. At peak, webhook delivery would stall, directly affecting customers who relied on Goldsky for real-time Web3 data to make trades and act on market signals.
The outbox pattern was already under strain at their current scale. As usage grew, it was clear: the system wouldn’t just slow down, it would fall over.
Why Sequin
Goldsky needed an alternative to the outbox—something more efficient, scalable, and easier to operate.
Sequin offered a fundamentally different architecture: change data capture (CDC) based on Postgres replication slots. Instead of writing to an outbox table, Sequin reads changes from a Postgres replication slot. Postgres replication slots were built for efficiently replicating changes. This approach eliminates polling and redundant writes entirely. And it comes with strong ordering and delivery guarantees.
Just as critically, Sequin handles end-to-end webhook delivery. Sequin’s managed deployment buffers messages from the replication slot to a highly available internal queue to ensure that no change is lost and that backpressure on a webhook sink never blocks replication. Messages are retained until delivered, with built-in retry, dead-lettering, and observability.
Sequin didn’t just replace the outbox, it provided a more scalable, reliable architecture.
Replacing the outbox pattern with CDC
Goldsky turned to Sequin to eliminate the outbox pattern entirely. The migration to Sequin was straightforward:
Goldsky opted for a fully managed Sequin deployment in the same availability zone as their four primary Postgres instances.
An end-to-end POC was up and running in the first couple days and then connected to the Production databases.
The Goldsky team wrote a script to gradually migrate roughly 700 webhooks sinks to Sequin using feature flags.
Throughout, the Sequin team provided performance tuning and support:
Sequin now powers change delivery across all four of Goldsky’s primary Postgres databases. It provides:
Reliable webhook delivery with built-in retries
Zero performance impact on transactional queries
Observability to ensure performance and simplify development
Massively reduced database IOPS
Head room to scale webhook delivery to 100x as many customers
50% reduction in IOPS and over $5,000 in monthly savings
Since switching to Sequin, Goldsky has seen p99 IOPS drop from 120k to 60k—unlocking immediate cost savings and more predictable performance:
Goldsky was able to scale down from r6i.32xlarge instances to r6g.16xlarge, significantly lowering RDS costs and saving thousands per month.
But more importantly, Sequin frees up engineering time while setting a foundation for reliable, scalable CDC into the future.
