Aurora data lake query support, GA as of September 30, lets your production Postgres read Apache Iceberg and Parquet straight out of S3. That sounds like a feature announcement. It is really a budget conversation, because a large share of most data teams’ pipeline estate exists for exactly one purpose: copying lake data back into the operational database so an application can show it. That copying now has a cheaper alternative.
The pipeline you’re quietly paying for
Here is the pattern almost every company with a data lake ends up running. Transactional data lands in Aurora. Some job ships it to S3, where the analytics team turns it into curated Iceberg tables: lifetime value, five-year order history, risk scores, churn flags. Then the product team asks to show that curated data inside the app. So somebody builds the reverse trip: a nightly or hourly job, maybe a third-party reverse-ETL subscription, pushing lake data back into Postgres tables.
That reverse trip carries four costs that rarely show up on one invoice:
- Duplicate storage. The same history lives in S3 and in Aurora storage, and the Aurora copy is the expensive one.
- Pipeline labor. Every schema change upstream breaks the sync. Someone owns that pager.
- Staleness. The app shows yesterday’s numbers because the job runs at 2 AM. Product calls this “eventually consistent.” Customers call it wrong.
- Tooling spend. Reverse-ETL vendors usually price by rows, syncs or connectors, and that bill grows with your success.
What changed with Aurora data lake query support
AWS embedded DuckDB, a fast open-source analytics engine, directly inside Aurora PostgreSQL 17.11+ and 18.6+. Your engineers define a “foreign table” that points at a table in the lake, and from then on the application queries it with ordinary SQL, joined against live operational data, without any copy. The AWS announcement spells out the headline: a single query can combine current transactions, including writes not yet committed, with years of history sitting in S3.
It works against the AWS Glue Data Catalog, Amazon S3 Tables, and external Iceberg catalogs federated through Glue, which covers most lakehouse setups we see. Teams that standardized on Apache Iceberg get the most out of it.
The cost model, in plain terms
There is no license fee and no new service. You pay for two things you already pay for: Aurora compute (the instance doing the work) and S3 request charges for reading files. Check current rates on Aurora pricing and S3 pricing, but the shape of the math is simple.
On the savings side, add up the reverse-ETL vendor subscription, the compute for sync jobs, the Aurora storage holding duplicated history, and the engineering hours spent fixing broken syncs. On the new-cost side, budget for one thing realistically: a dedicated Aurora reader instance for analytics if the workload is more than occasional. AWS recommends exactly that, and so do we. Frequently read data is cached on the instance’s local disk, so repeat queries do not keep paying S3 request charges.
For a pipeline that has been running a few years, that reader often costs less than what it replaces, before you even count the labor. Run your own numbers, but run them.
Where the risk actually sits
Two risks deserve a seat at the table. Neither is a reason to wait. Both are reasons to plan.
Compute contention on production. Analytical scans are heavy. Run a few large ones on the same instance that takes customer orders and you will notice. The mitigation is architectural and documented: route lake queries to a dedicated reader, give it the lowest failover priority so it never gets promoted to primary, cap how long a query can run, and set alarms on memory and cache metrics. AWS also built in protection that cancels a runaway analytics query before it destabilizes the instance. That is a guardrail, not a strategy. Isolation is the strategy.
Data governance. The cluster reads the lake through one IAM role, so whatever that role can see, the database can see. Access to individual tables inside Postgres is then controlled with standard database grants. That is a different control plane than your lake permissions, and someone must own keeping the two aligned. If your lake is governed through AWS Lake Formation, Lake Formation-governed tables are supported with additional permissions, but get your security team in the room before production, not after the audit.
A smaller operational note: the local cache is cleared on restart or failover, so the first queries afterward are slower until it warms back up. Plan for that in your SLOs.
When a warehouse still wins
This is not the end of the data warehouse, and anyone selling it that way is selling something. Keep Amazon Redshift or Amazon Athena in the picture when:
- Dozens of analysts run heavy, concurrent, multi-terabyte queries all day.
- You need to write back into the lake. Aurora’s lake tables are read-only.
- Workloads span data in several AWS Regions in one query, which this feature does not support.
- BI teams depend on warehouse-specific features such as workload management or data sharing.
The sweet spot is operational analytics: application-facing reads that combine live state with lake history, served to customers or internal tools at modest concurrency. That is precisely the territory reverse ETL was occupying.
A 90-day plan that doesn’t bet the company
- Weeks 1–2: Inventory. List every job that copies lake data into Aurora. Note the tables, the refresh frequency, the cost and who gets paged.
- Weeks 3–6: Pilot one. Pick a read-only, app-facing dataset with a tolerant SLA. Add an analytics reader, define the foreign tables, and run the new path in parallel with the old pipeline.
- Weeks 7–10: Measure. Compare latency, freshness, Aurora cost and S3 request cost against the pipeline. Confirm that permissions match your governance model.
- Weeks 11–13: Retire. Turn off the pipeline, drop the duplicated tables, cancel the seat licenses you no longer need, and repeat with the next candidate.
The engineering lift per dataset is small; your team’s existing Postgres skills carry over almost entirely. The organizational lift is deciding which copies you are finally allowed to delete. Make that decision deliberately, track the savings, and this becomes one of the rare infrastructure changes that is cheaper, faster and simpler at the same time.
At Enkompass (enkompass.net), this is our home turf. We’ve replaced reverse-ETL pipelines for clients by putting Aurora directly on top of their lakehouse data, sizing the analytics reader and the governance model so production never feels it. If you’d rather have seasoned cloud people handle it instead of learning the hard way at 2 AM, let’s talk. Reach out through our contact page or call us directly at +1-828-436-5667 — we’ll help you turn this from a someday-project into a done-deal.