Your Database Vendor Locks You In. Your Audit Trail Doesn't Have To.
Three of the biggest data platforms just shipped Postgres-compatible databases. The lock-in story everyone is debating — and the one nobody is — is what happens to your audit trail when you leave.
A strange thing happened this year.
Snowflake shipped a Postgres database. Databricks shipped a Postgres database. Microsoft shipped a Postgres database.
Three of the biggest data platform companies — all selling you a version of Postgres that keeps your data inside their ecosystem. Wire-compatible at the query level. Locked in at the operational level.
The article that caught my eye (Snowflake Postgres, Lakebase, HorizonDB: Picking the Lock-In You Want) broke this down clearly. You lose extensions. You lose logical replication. Your operational tooling breaks. Upgrade paths are now on someone else’s schedule.
That’s fine for some workloads. But here’s what the article didn’t talk about.
Your audit trail gets locked in too.
The hidden lock-in nobody mentions
When your data lives inside Snowflake Postgres, where are your access logs? Inside Snowflake Postgres.
When your data moves from Snowflake to Databricks, what happens to the proof of who accessed it and when? It stays behind. Or it gets recreated. Or you just lose it.
Most organizations don’t think about this until something goes wrong. An audit. A lawsuit. A regulator asking “prove what happened to this data.”
And suddenly you realize your proof is trapped inside a vendor’s format, a vendor’s log retention policy, a vendor’s idea of what an audit trail should look like.
That’s not compliance. That’s compliance theater with extra steps.
What portable proof looks like
We built VLI because this problem kept coming up. Not just with Postgres forks — with every data platform.
Every access event gets sealed at the moment it happens.
SHA-256 hash. Ed25519 signature. Chained to the previous event. Anchored to an independent registry.
The seal is not stored in your database. It lives alongside it. It references your data without being trapped by your database vendor’s choices.
Here’s what that means in practice.
You run Snowflake Postgres today. Next year you migrate to HorizonDB. Your VLI seals from last year still verify. The public keys are in the registry. The Merkle anchors are in the transparency log. The hash chains are in your audit bundles.
None of that requires Snowflake to still exist. None of it requires HorizonDB to support some proprietary audit format.
The proof is portable because the proof is math.
The question you should ask your database vendor
Not “do you support Postgres extensions?”
Not “what’s your read throughput at 3,000 vCores?”
Ask this: “If I leave your platform next year, what happens to my audit trail?”
If the answer involves exporting logs in some proprietary format and hoping they verify — you don’t have proof. You have a farewell gift.
If the answer is “we don’t know” — that’s honest, but it’s also a problem.
VLI’s answer is simple. Your seals stay valid. Your chain stays intact. Your proof works whether you stay or go.
Because trust that depends on the vendor isn’t proof. It’s faith with extra steps.
Lock-in is real. Your audit trail doesn’t have to be.
The three big data platforms are all building Postgres-compatible databases. They’re competing on performance, on scale, on lakehouse integration.
Those are real features. We’re not dismissing them.
But none of them is competing on audit portability. None of them is promising you can leave and take your proof with you.
That’s not an accident. Lock-in is the business model.
VLI is the escape hatch. Not from their performance. From their audit trap.
Use whatever database you want. We’ll seal what happens to your data. And when you leave — because eventually you might — your proof leaves with you.
That’s the difference between documentation and proof. Between vendor trust and mathematical independence. Between lock-in and portability.
Pick the database that fits your workload. Pick the provenance layer that outlives it.