Goldsky
Goldsky is the enterprise data platform for onchain finance and crypto-enabled products.
Goldsky separates control plane from data plane. The control plane orchestrates every customer workload: subgraphs for blockchain indexing, streaming pipelines for transforming blockchain data, and direct indexes into client databases. It also exposes the APIs that configure them: blockchain sources, database sinks, credentials, and access policies. All platform state lives here. If it's unavailable, customers can't create, modify, or scale their pipelines.
The challenge
Goldsky needed SOC2, which required encrypting their control plane database.
Because this database powers Goldsky's main API, the team could not afford a standard maintenance window. A dump-and-restore approach would take the platform offline.
The team faced three compounding constraints:
- Zero downtime. The migration had to happen while the application was live, serving reads and writes.
- Major version upgrade. Postgres 13 to an encrypted Postgres 17.
- Schema fidelity. Standard logical replication tools often create approximate schemas, preserving only primary keys and failing to replicate unique constraints. Goldsky needed the target to be an exact 1:1 replica before cutover.
Why Supermetal
- Zero data egress. Supermetal runs entirely within Goldsky's VPC. No customer data ever leaves their infrastructure.
- CDC for zero downtime. Unlike batch ETL tools, Supermetal provides real-time change data capture. Goldsky kept the new database in sync with production until cutover.
- 1:1 schema fidelity. Most migration tools only replicate primary keys. Supermetal honors the target schema's unique constraints and data types, ensuring the new database would be a drop-in replacement.
Migration deep dive
Paymahn Moghadasian led the migration. To keep the control plane online during the encryption process, the team executed a six-step deployment:
- Provision target. Spin up a new, encrypted Postgres 17 instance.
- Sync schema. Configure a secondary API deployment pointing to the new database, running CI/CD migrations to keep the target schema in sync (bypassing the Postgres logical replication DDL limitation).
- Replicate data. Deploy Supermetal to backfill historical data.
- Live sync. Run CDC until stable (about a day).
- Cutover. Point the main API to the new encrypted database.
- Cleanup. Wind down the secondary deployment.
Supermetal handled all data replication automatically. The initial rollout surfaced edge cases around unique index handling. The teams worked closely to resolve them, and once stable, the rest was straightforward.
Outcome
Goldsky migrated their control plane to the encrypted Postgres 17 instance with zero downtime. The move satisfied the final requirement for SOC2.
One day after the cutover, the legacy database, still serving another major workload, started failing. Because the control plane had already moved to new infrastructure, the incident was isolated to that workload. Had the migration been delayed, the failure would have taken down Goldsky's entire platform.
Using standard tools like pg_dump and pg_restore simply would not be acceptable because of the required downtime. Supermetal made the process seamless and completely transparent to our users.
— Paymahn Moghadasian, Software Engineer at Goldsky
What's next
This is Goldsky's second major migration with Supermetal. After using Supermetal to migrate terabytes of Graph Node data, Goldsky is now expanding its use across their infrastructure, including CDC to Kafka for real-time streaming and a real-time customer data platform (CDP).