Most of the decisions that decide a platform's fate are invisible to the people who use it.

A dealer does not care what file format their inventory lives in. A workshop manager does not ask whether vehicle history is stored as Parquet behind an open table spec or locked inside a vendor's proprietary database. They care that the screen loads, the valuation looks right, and the car sells.

And yet the storage decision is one of the few that you cannot easily undo. Pick the wrong one early and you spend the next decade paying for it - in migration projects, in lost leverage during renewals, in data you technically own but cannot actually move. Pick the right one and you build an advantage that compounds quietly while nobody is watching.

This is the case for open table formats - Apache Iceberg in particular - in automotive software. It is a technical argument with a strategic conclusion: own your data, store it in open formats, and you have made a one-way-door choice in your favor instead of against yourself.

What "open format" actually means

Strip away the jargon and there are three ways data can sit on disk underneath a platform.

The first is a closed, proprietary database engine. Your data is real, but it only makes sense to the vendor's software. To get it out, you export - and exports are lossy, slow, and always a little out of date the moment they finish.

The second is files in an open columnar format like Parquet, dumped into object storage. Better. Anyone can read a Parquet file. But raw files have no notion of tables, transactions, schema history, or time. You get bytes, not a database.

The third is an open table format - Iceberg, and a small number of peers - layered on top of those open files. Iceberg adds the things that make a pile of files behave like a real, governed table: ACID transactions, schema evolution, snapshots you can query as of a point in time, and a metadata layer that any compliant engine can read. Crucially, the spec is open and the files are yours. Spark can read them. DuckDB can read them. A query engine you write yourself can read them. No single vendor sits between you and your own records.

The difference is not academic. It is the difference between data you possess and data you merely have access to.

Why automotive is unusually sensitive to this

Every industry has data. Automotive has a specific shape of data that makes the storage choice matter more than most.

Vehicles are long-lived and multi-owner. A single car generates records across a decade or more - registration, valuations, service events, damage, ownership changes, financing, eventual resale. The data outlives any one dealer's relationship with the vehicle, and often outlives the software contract that first captured it. If that history is trapped in a format you cannot port, the vehicle's story breaks every time a system changes hands.

The data is canonical, not disposable. A VIN, a registration, a mileage reading, a damage record - these are facts about the physical world that other systems depend on being correct and consistent. When data is canonical, lineage matters. You need to know not just the value but where it came from, when, and from which source. Open table formats give you snapshots and history as first-class features. You can answer "what did we believe about this car on this date, and why" without rebuilding the past from logs.

Regulation now assumes portability. The EU Data Act reframes data access as a right, not a favor. The direction of travel across European policy is clear: the entity that generates data should be able to access it, move it, and share it on fair terms. A platform whose data is locked in a proprietary store is fighting that current. A platform whose data is already in open formats is swimming with it. Sovereignty stops being a compliance scramble and becomes a property of the architecture.

Put those three together and the picture is stark. Automotive data is long-lived, canonical, and increasingly governed by a right to portability. Storing it in a format you cannot freely move is a structural liability that grows every year the platform runs.

The one-way doors, in both directions

Borrow the framing of reversible and irreversible decisions. Most product choices are two-way doors: try it, and if it is wrong, walk back through. Storage format is a one-way door. The asymmetry is what makes it strategic.

Choose a proprietary store and the door swings shut behind you. Every record you write deepens the dependency. Migration becomes a multi-quarter project with its own risk profile, so it keeps getting deferred. The lock-in is not a clause in a contract - it is a property of your own data gravity. You stay because leaving is expensive, not because staying is best.

Choose an open table format and the door swings the other way. The lock-in inverts. You can change query engines, swap cloud providers, hand a partner a governed copy, or stand up an entirely new application on the same tables - without a migration, because there is nothing proprietary to migrate from. The data is the asset; the software is just one of many readers of it.

This is why the advantage is invisible to customers and decisive for the long game. On any given Tuesday, the two architectures look identical from the dashboard. The difference only shows up at the moments that matter most: a contract renewal, a regulatory request, a platform acquisition, a partner integration, a decision to rebuild a stale component without touching the data it reads. At those moments, one architecture gives you options and the other presents you with a bill.

What you get when you own the tables

Concretely, here is what falls out of storing canonical vehicle data in an open table format and owning it outright.

Portability without ceremony. Moving data is a copy, not a project. There is no proprietary export to reverse-engineer, no fidelity lost in translation. The same files that power production can be handed to an analyst, a partner, or a regulator.

Auditability by construction. Snapshots and schema history mean you can reconstruct exactly what the system knew at any past moment. For valuations especially, this matters - being able to show the inputs as they stood when a number was produced is the difference between a defensible figure and a guess. Lineage stops being a feature you bolt on and becomes a side effect of how the data is stored.

Multiple engines, one source of truth. Batch analytics, ad-hoc queries, machine-learning features, and the live application can all read the same governed tables. You are not maintaining copies that drift apart. One set of facts, many consumers.

Sovereignty you can point to. Open files in EU storage, readable by tools you control, are a sovereignty story you can actually defend in a procurement review - not a promise, but an architecture diagram.

None of this requires the customer to understand any of it. That is the point. The best infrastructure decisions are the ones the user never has to think about, because they were made correctly once and then quietly paid dividends forever.

The quiet test for any platform

So here is a fair question to ask any automotive platform, including ours: if you walked away tomorrow, what could you take with you, and in what shape?

If the honest answer is "a stale CSV export and a support ticket," the data was never really yours. If the answer is "every record, in an open format, fully governed, ready to read on day one," then the platform made the right one-way-door choice - and so did you, by building on it.

At VehIQ, canonical European vehicle data lives in open table formats with field-level lineage, in EU storage, owned outright. Not because customers ask for Iceberg by name - almost none ever will - but because the trust layer for European automotive should be built on data you can always pick up and carry. The right foundations are the ones you never have to think about again. We would rather you never have to.