I’ve been reading a lot about "Zero ETL" initiatives from AWS and Salesforce. As a data engineer who spends 80% of my time building pipelines, this sounds too good to be true. Can we really eliminate the transformation layer, or are we just shifting the complexity somewhere else? I'd love to hear real-world experiences.
3 answers
That makes sense, but doesn't Zero ETL lock you into a specific vendor's ecosystem even more tightly than before? How do you maintain a multi-cloud strategy with these native links?
Zero ETL is definitely more of a "Reduced ETL" reality. The idea is to have native integrations—like Amazon Aurora to Redshift—where data is moved automatically without you writing a Python script or a dbt model. However, this only handles the "Transport" part. You still need to transform that raw data into a usable format for BI tools. In my current project, Zero ETL saved us weeks of ingestion work, but we still spend significant time on data modeling and business logic. It removes the "plumbing" but doesn't replace the need for an architect to define the data's meaning.
It’s great for simple replication, but for complex joins across multiple disparate sources, a traditional ETL/ELT pipeline is still very much a requirement.
Exactly, Michelle. Once you need to join Salesforce data with an on-premise SQL Server, the "Zero" part of the equation disappears immediately.
That is the primary trade-off, William. By choosing Zero ETL, you are effectively trading portability for speed. In our case, the speed of delivery for the business outweighed the risk of AWS vendor lock-in. However, we keep our core transformation logic in SQL via dbt, which remains relatively portable. We use the native links for the "Extract and Load" but keep the "Transform" layer as vendor-neutral as possible to mitigate that risk.