ACID are four promises a database makes about transactions: Atomicity, Consistency, Isolation, Durability. A transaction is a group of changes that should be treated as one unit.
An example with a pipeline load
You load one day of orders and the matching order_items rows. Both tables must end up in step.
- Atomicity: all or nothing. If the load fails after inserting orders but before items, the database rolls back the orders too. You do not get 10,000 orders with no items.
- Consistency: the data respects the rules after the transaction. A NOT NULL, a unique key or a check constraint is never violated by committed data. (In cloud warehouses a lot of these rules are not enforced, so this guarantee is weaker than people assume.)
- Isolation: concurrent work does not see half-finished changes. The dashboard that runs while your load is halfway sees the old data or the complete new data, not a mix.
- Durability: once the commit returns, the data survives a crash or power loss, because it has been written to durable storage or a log.
BEGIN; INSERT INTO orders SELECT * FROM stg_orders; INSERT INTO order_items SELECT * FROM stg_order_items; COMMIT; -- both or neither
Why this matters in data engineering
Plain files on object storage (Parquet in S3) have none of this. A job that writes 200 files and crashes at file 120 leaves a half-loaded folder, and a reader can pick up the partial output. Table formats such as Delta Lake, Apache Iceberg and Apache Hudi add a transaction log or metadata layer on top of the files. A write only becomes visible when the log entry is committed, which brings atomic commits and isolation to a lake.
Related question
"Is a warehouse ACID?" Mostly yes at the table level. Snowflake and BigQuery both give atomic statements, and multi-statement transactions are supported with limits. The details differ per engine, so say what you know and do not claim more.