Delta Lake: when the company stands on Microsoft

A company has run on Microsoft for fifteen years. Mail, documents and meetings in Microsoft 365, reports in Power BI, and lately a Fabric workspace where the data team lands extracts from the ERP. When such a company considers an operating system for the whole business, the first question from IT is reasonable: does the record end up somewhere our tools can still read?

For a company in that position the answer runs through Delta Lake. OneLake, the storage under Fabric, keeps its tables as Delta Parquet according to Microsoft’s documentation, so a record in Delta is a record Fabric can read without a copy. Hurukan’s integration with Microsoft 365 Copilot is planned, not live, and the Data layer is in build; this text is about what Delta Lake gives the record in that setting, and what remains the company’s to decide. Why the record exists at all is in the live state and the record.

What the log does

Delta Lake adds one thing to a directory of Parquet files: a transaction log. _delta_log/ holds one JSON file per commit, named by version, each listing which files were added or removed and what the schema and protocol are. Periodic Parquet checkpoints summarise the log so a reader does not replay it from the start. The protocol document defines this; release 4.4.0 is current (checked 21 October 2026).

From that one mechanism follows everything the record needs. A write is atomic because the commit file either exists or does not. Readers see a whole version because they read a numbered commit, not a directory listing. Two writers do not corrupt each other because optimistic concurrency detects the conflict at commit time. And “the table as it was when the agent proposed this” is a version number, which is what makes the audit question answerable.

The features that matter for a record

Delta’s table features are enabled per table and carried in the protocol, so a reader knows whether it can read what it is looking at. The versioning page lists them with the reader and writer versions they require (checked 21 October 2026). Four of them shape a company record.

Deletion vectors mark rows as removed without rewriting the file, so a deletion request for one person does not rewrite a year of invoices. The removal becomes final when the old files are vacuumed, which is a retention setting, not an automatic effect.

Change Data Feed exposes what changed between two versions, which is how downstream tables and agents learn about a change without rereading everything.

Liquid clustering replaces fixed partitions with clustering keys that can change later, so the layout can follow how the record is actually queried.

UniForm writes Iceberg metadata beside the Delta log, so engines that read Iceberg see the same table. It requires column mapping, is read-only from the Iceberg side, and has documented limits around deletion vectors and change data, described under Delta UniForm. The series text on XTable and UniForm goes into what that buys.

What Fabric manages, and what it does not

A managed platform takes real work off the company’s hands: storage, compute, the engines, the Power BI connection, and increasingly the maintenance jobs. It is a sensible place for a record if the company has already decided to stand on Microsoft. Four things remain the company’s whether or not it notices.

The catalogue. OneLake decides what a table is called, who may read it and where the current version is declared. The files are open; the directory of files is the platform’s. An exit plan that says “we have Parquet in a lake” has not accounted for that directory.

Retention and deletion. Log retention and vacuum thresholds are table settings. They determine how far time travel reaches and when a deleted person is actually gone. Nobody at the platform sets them for you, and an agent in Hurukan may propose them but does not approve them.

Feature enablement. Turning on a newer feature raises the protocol version and can lock out an older reader elsewhere in the company. The gain is real; so is the reader that stops working. A person decides, per table, with the list of readers in front of them.

The write path. Delta can be written by many engines, but the engine that writes a given table is a design decision, because it is where ownership of the data sits. In Hurukan the modules write through the record’s own path and the platform reads; the reverse is a different architecture.

Which of these the company owns is exactly the question under security and sovereignty: infrastructure the company chooses, data and models that stay the company’s, an exit that is possible in practice.

Where agents help, and where they stop

The maintenance of a Delta record is mechanical and continuous: compaction, vacuum, statistics, clustering. Agents draft these jobs well, and they explain a slow query better than a dashboard does. In Hurukan each such job is a proposal in the approval inbox with its reasoning attached, approved by a person and recorded like any other change.

What agents do not do is decide retention, approve a protocol upgrade, or choose the write path. Those three decisions set what the record can prove later, and a company has to be able to say who made them.

A test you can run today

Open one table your Fabric workspace already holds and find three settings: its log retention, its vacuum threshold, and the protocol version it requires of a reader. If the three are where the platform left them, nobody has yet decided how far back your record reaches or which of your tools will be able to read it next year. That is the first decision a company record needs, and it costs nothing to make.