Principles
What makes a lakehouse open
"Open" is used loosely enough that it has stopped carrying much information. These five commitments are what the word has to mean for the architecture to deliver what it promises. Each one comes with a test you can actually run against a system, rather than a claim you have to take on faith.
- 01
The data is in open formats you can read without permission
Anyone can implement the spec.
Every byte sits in a publicly specified format: Parquet, ORC, or Avro for the files, and an openly published table format for the metadata. Specification matters more than licence here. A format controlled by one vendor but documented well enough for others to implement is more open in practice than one that is nominally open source but that only its author can read correctly.
The test Could a team with no relationship to any vendor write a correct reader from the published specification alone?
- 02
Storage and compute scale and bill separately
Neither one holds the other hostage.
Data lives in object storage you control. Compute is attached to it, sized for the workload, and shut down when idle. This is what makes retaining full history affordable, and it is what lets a small query run on a small engine instead of paying for a cluster sized for the largest job on the platform.
The test Can you turn off every query engine overnight and still have all of your data, readable, in the morning?
- 03
More than one engine can read and write the same tables
Engine choice is a runtime decision, not a migration.
The point of an open table format is that Spark, Trino, Flink, DuckDB, and a commercial engine can all operate on the same tables with consistent semantics. Read compatibility is the easy half. Write compatibility, where two engines can safely commit to the same table without corrupting it, is the part that separates real interoperability from a checkbox.
The test Can a second engine write to a table the first engine created, concurrently, without corrupting it?
- 04
One catalog governs access, and it speaks an open API
Governance lives with the data, not in each engine.
When several engines share tables, they need a single authority on which tables exist, where the current metadata lives, and who may read or write them. Enforcing permissions inside each engine means maintaining the same rules in several places and hoping they agree. A catalog with an open API keeps that authority in one place and keeps it swappable.
The test If you revoke access in the catalog, does every engine lose access, including the one you forgot about?
- 05
Leaving costs no more than arriving
No proprietary round trip.
The practical test of openness is exit. If adopting a component means converting data into a format only that component reads, the architecture has a lock-in point regardless of what its documentation claims. Ingesting into open formats and querying in place keeps the exit cost close to zero, because leaving means pointing a different engine at storage you already own.
The test To replace any single component, would you have to rewrite your data?
Openness is a spectrum, not a badge
Very few production platforms satisfy all five completely, and that is fine. The value of stating them plainly is that it turns a marketing adjective into a set of specific questions. A platform that fails principle three is not disqualified; it just has a known constraint you can plan around, rather than an unknown one you discover during a migration.
The reference architecture shows which layer each principle constrains, and the comparisons apply these tests to the specific technologies that occupy each layer.