The numbers in a table were wrong in the morning, and they had been right the evening before. Something had written to it at two in the morning. I needed to know what that write did.

Today

The table was a Delta table in a bucket: a folder of parquet files with a folder called _delta_log beside them. I knew the history lived in that folder. The console showed it to me as a list of files named with long, zero-padded numbers, a JSON file per commit, with sizes and dates.

So I downloaded the last few and opened them in an editor. Each one is a file of JSON lines: which data files the commit added, which it removed, what kind of operation it was, some counts. Reading them by hand worked for one commit and fell apart at three, because the answer I wanted, "what did the table look like before", is spread across all of them. So I started a query engine with the right extension, pointed it at the table, and asked it for the history. That was the part that took the morning.

1. Cloud consolea log folder
2. Cloud consoledownload a few
3. Editorread JSON by hand
4. Terminalstart an engine
5. Query consoleask one question

a query engine started to read a folder of JSON

Nobody did anything wrong. The table format did exactly what it was designed to do, and did it well. The console showed the files it had. The shared assumption was that a table's history is an internal detail that needs an engine to read, rather than a document written for people too.

Ideal

So I looked at what that folder actually is. It is not an accident of storage. The table writes down every change it makes, in order, on purpose, so that any reader can replay it and agree on what the table contains. Commit zero, commit one, commit two. Each says what it added and what it removed. That is a history already, in the most literal sense.

If that is true, then showing it needs no engine at all. Read the commits, oldest to newest, and for each one draw what it did: the operation, when, how many rows, and the files that came and went. Iceberg keeps the same idea as a chain of snapshots, and Hudi as a timeline of instants. Different words, the same shape.

The _delta_log folder of demo/delta/sales opened as a history: v0 WRITE adds 4 rows in one file, v1 UPDATE swaps that file for a new one, v2 DELETE removes 2 rows, each commit with its time and the files it added (+) and removed (−).

That is a small Delta table's log, opened as its history. The first commit wrote four rows in one file. The second was an update, which in this format means the old file is replaced by a new one, and the log says so: one file added, one removed. The third deleted two rows the same way. In the code, a folder is recognised as a Delta log by its commit files alone, whose names are the version padded to twenty digits, and the same history view exists for Iceberg snapshots and for the Hudi timeline.

Where it stops

I can see every commit. I can't yet look at the table as it stood before one of them. Reading the table always reads its latest version; the query path has no way to ask for version one instead of version two. For the two in the morning problem, that means the history tells me what happened and which files were involved, and restoring or comparing still takes an engine that can time travel.

Very long logs are also cut off: the view shows a fixed number of versions and says so, rather than reading thousands of commits to draw them.

Every commit, on a timeline.