Aestus reads each committed change from the database's own log and applies it to the target in order, with the version of the change stored on every row. Replicate between vendors, feed the lakehouse, or turn documents into tables and tables into documents, graphs and search indexes.
How Aestus reads changes from each system, and how it writes them.
As a source: Logical decoding through a replication slot and a publication. The initial load starts from the slot's own snapshot, so nothing is missed between load and stream.
As a target: Tables created and widened on demand; JSON columns as JSONB; vectors as pgvector columns.
As a source: Row events from the binary log, with GTIDs to resume after a failover.
As a target: Tables with a transaction per batch and a savepoint per record, so one bad record never blocks the rest.
As a source: Change Data Capture for full rows, or the lighter Change Tracking with a fresh read of each changed row.
As a target: Tables, JSON as text, and vector columns on SQL Server 2025.
As a source: LogMiner on the redo and archived logs, ordered by SCN. The initial load reads the tables as of one SCN.
As a target: Tables through a pure-Go driver, no Oracle client to install; vector columns on Oracle 23ai.
As a source: Triggers that record each change in a change-log table, for edge devices and embedded applications.
As a target: Relational tables from a mapping, or documents stored as they are.
As a source: The Delta Change Data Feed, with inserts, updates (before and after) and deletes per commit version.
As a target: Delta tables with documents kept as VARIANT, typed columns, and optional change history.
As a source: Change tracking with the CHANGES clause: the net change of every row since the last read.
As a target: Tables with semi-structured data as VARIANT.
Between systems of the same kind, and across kinds through a transform.
Same schema on another server, another cloud or another vendor: Oracle or SQL Server to PostgreSQL, MySQL to Aurora, many regional databases into one.
Databricks and Snowflake tables that follow production within minutes instead of a nightly batch, with optional history of every version.
A collection becomes a parent table, embedded arrays become child tables, nested fields become typed columns. Tables grow as the documents do.
A row and its child rows become one document: ready-made read models for APIs and applications that should not query the system of record.
Rows become nodes, foreign keys and join tables become relationships, for fraud, recommendation and dependency analysis.
Text columns are chunked and embedded into a vector store or a search index, which follows every update and delete.
Run the old and the new database side by side, kept in step change by change, and switch over when you are ready. No freeze, no big-bang weekend.
Move heavy reports and BI queries to a copy that is seconds behind production, so they never slow down the application.
Feed Databricks or Snowflake continuously. Analysts and models work on today's data, not last night's.
Bring tens of tenant, regional or acquired databases together into one database for reporting and operations.
Give each service its own read copy of the data it needs, instead of a shared database every team is afraid to change.
Keep every version of a row with valid-from and valid-to times, for audits, investigations and slowly changing dimensions.
Every row stores the version of its last change; a late or repeated change is ignored.
A deleted row leaves a tombstone, so a late insert cannot bring it back.
Each record is applied in its own savepoint; a failing one is read again from the source.
Tables are created and new columns added when the data needs them.
Document, key-value and wide-column stores: MongoDB and its relatives, DynamoDB, Firestore and Cassandra.
ExploreProperty graphs in Neo4j and Neptune, and graphs kept inside PostgreSQL, MongoDB, SQL Server and Oracle.
ExploreSearch engines and vector stores that serve search, recommendations and AI assistants.
ExploreApplication APIs and the enterprise message brokers: deliver changes into systems and onto event streams, or start a flow from them.
ExploreWant to discuss your use case? Write to info@aestus-cdc.com.