Apache Iceberg is the clipboard-wielding manager that walks in and says: "Right. Let's make this place behave like an actual database."

It's an open table format that sits on top of your files (Parquet, ORC, etc.) and adds a smart metadata layer. That metadata is where all the magic happens:

Let's tour the highlights, using a food delivery app's orders table as our example. 🍜🛵

1. ACID Transactions: All or Nothing 💥

The order service and the payment service both write to the orders table at the same time. In the old data lake world, that could mean corrupted or lost data.

Iceberg uses optimistic concurrency. It assumes writers won't clash, lets them work freely, and only checks for conflicts at commit time. The catalog acts as the referee:

Each write either fully commits or fully fails. No half-saved orders, no missing nasi lemak.

2. Row-Level Updates: Rewrite or Leave a Note? ✍️

Files in a data lake are immutable: you can't edit them in place. So what happens when a customer cancels order 1234?

Iceberg gives you two strategies:

With MOR, the "ignore this" note comes in two flavours:

• Positional delete: "Skip row #234 in file_2." Precise and fast to read.

• Equality delete: "Skip any row where order_id = 1234." Super cheap to write, which makes it great for streaming.

Plot twist: What if the customer changes their mind and order 1234 gets placed again? Won't the old delete note hide it too?

Nope. Iceberg stamps every change with a sequence number, and a delete note only applies to data that came before it:

The cancelled order stays gone and the new one shows up. 🕰️

3. Partition Evolution: Change Your Mind for Free 🔄

You partitioned orders by month back when the app had a few hundred users. Now you're doing thousands of orders an hour and want daily partitions.

In the old world, that meant rewriting the entire table. 😱 With Iceberg, you just update the partition spec:

Old data stays where it is, new data lands in daily partitions, and queries handle both automatically. It's a metadata change, so it's quick and cheap.

4. Hidden Partitioning: Stop Thinking About Folders 🙈

Old-school tables often had extra columns like order_year, order_month, order_day just for partitioning. If an analyst filtered on order_timestamp instead, the result was a full table scan. Ouch.

Iceberg partitions using transforms like day(order_timestamp), month(), bucket(), or truncate(). You filter on the column you actually care about, and Iceberg handles pruning behind the scenes:

-- Just write the natural query. Iceberg does the rest.
SELECT * FROM orders
WHERE order_timestamp >= '2026-10-01';

5. Time Travel & Rollback: Query the Past, Undo Mistakes ⏳⏪

Every change creates an immutable snapshot, so the table keeps its own history:

Time travel: Want to see exactly what orders looked like at the end of last month? Query that snapshot directly. You don't need to copy the table first.

SELECT * FROM orders FOR TIMESTAMP AS OF '2026-09-30 23:59:59';

(Exact syntax varies a little by engine.)

Rollback: A buggy job loaded every order twice and now the dashboard says you sold 10,000 bubble teas before lunch? Roll the table back to the previous snapshot. Mistake undone. 🧋

6. Schema Evolution: Tables Grow Up 🌱

Add a delivery_rider_id column, rename addr to delivery_address, or widen types. For example, when order_id outgrows an int because the app got popular, you can promote it to a long without rewriting your data.

TL;DR 🧊

Apache Iceberg turns a messy pile of files into a proper table with:

• Safe concurrent writes (ACID)

• Flexible updates and deletes (COW / MOR)

• Painless partition changes

• Queries that don't need partition trivia

• Time travel and rollback

• Schema changes without drama

Your data lake isn't sinking anymore. It's floating. 🚢

Next up: I'll dig into how Iceberg's metadata layers actually work under the hood. Stay tuned!