Document and NoSQL databases hold the data of modern applications. Aestus follows their change streams and feeds, keeps related records in order, and delivers the changes as documents, rows, graph elements or search entries.
How Aestus reads changes from each system, and how it writes them.
As a source: Change streams on replica sets, sharded clusters and Atlas, with an initial load, full documents or changed fields only, and split readers for busy collections.
As a target: One document per record with child rows embedded as arrays, or documents stored as they are; changed fields are applied in place.
As a source: The MongoDB-compatible change streams, or the native Cosmos DB change feed.
As a target: Documents through the MongoDB-compatible interface.
As a source: DynamoDB Streams with old and new images, or Kinesis Data Streams for longer retention; exports to S3 for the initial load.
As a target: One item per record with children embedded; tables created on demand; every write is conditional on the version.
As a source: Listeners on collections, and exports for the initial load.
As a target: Documents and subcollections.
As a source: The CDC commit log, read next to every node.
As a target: Tables where each write carries the change's version as its timestamp, so Cassandra itself keeps the newest.
Between systems of the same kind, and across kinds through a transform.
Copy collections between clusters, regions and clouds: Atlas to DocumentDB, DynamoDB to MongoDB, on-premises to Atlas.
Map collections to parent and child tables with typed columns, for SQL, BI tools and the lakehouse.
Assemble a row and its child rows into one document, so applications read one document instead of joining tables.
Fields that point to other documents become relationships in Neo4j or Neptune.
Descriptions, tickets and articles are embedded and indexed as they change, with their metadata.
Whole documents land as VARIANT in Delta tables, with the fields you query most as typed columns.
Report on what happens in your MongoDB or DynamoDB application in SQL, without exporting and without load on production.
Move from one document database or cloud to another while the application keeps running.
Build documents shaped for each screen or API from the system of record, and keep them current.
Keep copies close to users in other regions, or at the edge, without writing replication code.
Feed changes from modern applications into the SQL databases of ERP, finance or legacy systems.
Let assistants and search work on documents as they are now, not on last week's export.
Group collections by a key, such as an item and its stock: changes for one group arrive in order.
Tombstones stop late changes from bringing back deleted documents.
When a change cannot be applied on its own, Aestus reads the current document again instead of guessing.
Send whole documents, or only the fields that changed when the target can apply them.
Operational, reporting and analytical SQL databases, from PostgreSQL to the lakehouse.
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 [email protected].