CDC Bridge
What it is
Section titled “What it is”The CDC bridge turns AetheriusDB into a high-speed analytical and vector sidecar for an existing transactional database. It speaks the native replication protocol of Postgres (logical replication slots) and MySQL (binary log) directly, so every committed row in the source flows into AetheriusDB within milliseconds. Keep your writes on the legacy database and point your analytics, search, and AI workloads at AetheriusDB without changing the application.
Schema changes ride along automatically: when you ALTER TABLE on the source, the
bridge sees the DDL in the replication stream and applies an equivalent change on
the AetheriusDB side. Because mirrored history is tracked, you can branch a copy of
the data for testing or run point-in-time queries against an earlier moment.
Why use it
Section titled “Why use it”The bridge is a zero-migration upgrade path. Install AetheriusDB next to your existing database, point the bridge at the replication endpoint, and your analytical queries — vector search, large joins, billion-row aggregations — run on a much faster engine while writes stay where they always were.
- No external CDC stack — the bridge is part of the database, not a connector you deploy.
- Sub-second freshness — replication lag stays in the low-millisecond range under normal load.
- Schema-aware — DDL on the source applies automatically on the target.
sequenceDiagram participant App participant PG as Legacy DB participant Bridge as CDC bridge participant AE as AetheriusDB App->>PG: INSERT / UPDATE PG-->>App: COMMIT PG->>Bridge: replication record Bridge->>AE: apply row change AE-->>Bridge: durably applied Bridge->>PG: ack position
How to use it
Section titled “How to use it”Declare the bridge with CREATE BRIDGE, supplying the legacy connection details
and which tables to mirror. The engine maintains the replication slot, applies
schema changes, and reports lag through the system catalog.
-- Bridge a Postgres database. The replication slot is created automatically.CREATE BRIDGE prod_pg FROM TYPE 'postgres' OPTIONS ( host = 'prod-db.example.com', port = 5432, user = 'replicator', slot = 'aetherius_mirror' ) MIRROR (public.orders, public.customers, public.products);
START BRIDGE prod_pg;
-- Inspect freshness.SELECT source_table, target_table, lag_ms, last_applied_lsn FROM aether.bridge_status WHERE bridge_name = 'prod_pg';Once started, every committed row on the source appears in the mirror with only a few milliseconds of lag. Run a heavy join against the mirror without affecting the legacy database at all.