Built for Google Cloud databases.

Source and target

Cloud Spanner

Move into Spanner at PU-saturating throughput.

Wirekite Data writes into Spanner with blind-write semantics on top of the native Spanner client — no read-write transactions, no row-by-row inserts. Files are PK-sorted on the source side, then loaded through the engine-native write path, sized to the instance.

• Per-file pipeline: scanner → 4 parsers → 2 writers, idempotent InsertOrUpdate mutations.
• Capacity scales with instance size — Wirekite fills the available throughput greedily, with no PU left idle.
• Incremental pre-splitting for large tables so writes spread across nodes from the first batch instead of bottlenecking on a single split.
• Source via Spanner change streams for CDC into your warehouse of choice.

Target

BigQuery

Load jobs on extract. MERGE on apply.

Wirekite stages every extracted file to your own GCS bucket, then drives BigQuery load jobs to land them in the target dataset. For change streams, the loader generates type-aware MERGE statements that apply inserts, updates, and deletes in commit order.

• Service-account auth — minimum roles are jobUser plus storage.objectAdmin on the staging bucket. No project-wide privileges.
• DSN names a project, location, and GCS bucket; datasets are picked per-migration so one connection serves many.
• Type-aware mapping for timestamps, NUMERIC precision, JSON, and NULL handling across source dialects.
• Test Connection plus a separate Test GCS Access button in the UI so credential errors land before the migration starts, not during it.

Source and target

AlloyDB for PostgreSQL

Same logical-replication path as Postgres.

AlloyDB is Postgres-protocol compatible, so Wirekite uses the same engine-native replication pipeline that drives 1.2B changes per hour on stock Postgres. Both sides — extract and load — are battle-tested on the same engine class.

• Engine-native CDC capture, the same model we publish 1.2B/hr sustained throughput on.
• Bulk loads use COPY on the target side, sized to AlloyDB's write throughput.
• Drop-in destination for an Oracle → AlloyDB migration — the most common Wirekite cloud-migration use case.
• Validate runs sorted-by-PK column-by-column verification after the move, with type-aware comparison.

Source and target

Cloud SQL for MySQL

Engine-tuned capture. Native LOAD DATA on load.

Cloud SQL MySQL runs the standard MySQL binlog and ingest paths, so Wirekite drives it the same way it drives self-hosted MySQL — engine-tuned capture on the source side, native LOAD DATA on the target side.

• Engine-tuned capture saturates CPU, disk, and network simultaneously.
• Target writes go through MySQL LOAD DATA, not row-by-row INSERTs — every byte handled by the engine, not the wire.
• Same source path that hits 53s for ten million MySQL CDC operations into Firebolt on real hardware.
• First-class for the Cloud SQL → BigQuery analytics pipeline.

Source and target

Cloud SQL for PostgreSQL

Logical-slot CDC. COPY-driven loads.

Cloud SQL Postgres uses the same logical-replication path as AlloyDB and self-hosted Postgres. Wirekite captures CDC through engine-native paths and lands bulk data through Postgres COPY on the target side.

• Engine-native logical replication — no single-stream ceiling.
• End-to-end Postgres → Postgres throughput measured at 307K row changes per second with the loader applying every change.
• Bulk extract and load both run through engine-native COPY at full target throughput.
• Combine with Validate to prove the move row-by-row before flipping traffic.