Starts from the snapshot
No agent to install, no replication, no CDC. The snapshot AWS already takes is the source — including for databases in another account.
runs in your AWS accountin production for over a year
Your production database
never has to know analytics exist.
Data Pump starts from the snapshot AWS already takes every day. It exports, organizes and catalogs it — and what comes out is queryable in Athena. Nothing connects to the live database.
A snapshot is a copy frozen in time. Everything comes from there — no query ever touches production, not even to find out which tables exist.
one table, end to end
AWS takes the snapshot
RDS exports it as Parquet
exported/{cluster}/{export}/pagila/public.payment/Data Pump organizes and renames
catalog/{cluster}/pagila.pagamentos/Repartitions by what you query
catalog/{cluster}/pagila.pagamentos/ano=2024/mes=03/Glue catalogs it
Five steps, none of them inside your database
The pipeline fires on its own when a snapshot is ready. From notification to catalog, nobody intervenes.
Exports where the data lives
Cross-account, the export runs in the source account and writes straight to your bucket. Raw data never travels twice.
You decide what comes in
Pick the databases, filter tables, and rename anything with a cryptic name. `tb_pgto` becomes `payments` in the lake.
Partitions by what you ask
A table repartitioned by year and month lets Athena read only the slice your query needs — not the whole table.
Keeps what the database drops
Long-term history is not wiped on each run. Purge old rows from Postgres and they stay queryable here.
Shows what happened
Every run records its steps, which tables were touched, and the version of each component. When it fails, the error is visible.
The alternative is touching the database that cannot stop
Every way of getting data out of a live Postgres has a price. Starting from the snapshot has the smallest one.
query it directly, or replicate
- Analytical queries compete with the application
- A replica needs database config and someone to maintain it
- CDC needs its own agent, connector and monitoring
- Network access to the database becomes a security exception
- Purged data disappears with it
start from the snapshot
- The database gets no new connections at all
- AWS already takes the snapshot — that cost exists anyway
- Nothing installed at the source, not even across accounts
- No network route: the pipeline reads files, not the database
- History survives the purge
A dashboard in your infrastructure, not ours
All of Data Pump runs in the customer AWS account — the console included. Your data never passes through us.
Sources and databases
Mark which clusters feed the lake and which databases get ingested. The table list comes from the export itself.
Partitions
Set how each table is repartitioned, and what happens when a row changes in the database after it was already ingested.
Runs
Follow each run step by step, see which tables were updated and what failed, with the log for that step.
Want to see it running in your environment?
Every installation starts with a conversation: we settle the account, region, VPC and source databases, then build a package for that setup. There is no generic installer — tell us your case and we will reply with what fits.