Head-to-head · updated 13 September 2026

DataShield vs Onehouse: the lakehouse is fast enough for agents now. Who checks what they read?

Onehouse is a serious piece of data infrastructure, honestly. The very people who built Apache Hudi built it. They gave OneTable to the Apache Foundation, as XTable. Their pitch is blunt: "One Data Lakehouse. Any Cloud." Your files stay in your own buckets. Ingestion, table upkeep, a Spark runtime. A fast Postgres-shaped serving layer sits on top of all that. Is your Databricks bill the problem? Then they do have a real answer. We have no interest at all in arguing with their TPC-DS numbers.

We are simply not a lakehouse. DataShield is the checked data plane. It's the evidence layer for what agents do with data. We tokenize datasets right at ingest. Agents then query tokenized data over MCP. Detokenization is a privileged, audited step. We re-check each checked tool call against the agent's current access. That happens before it runs. We seal each decision into a hash chain anyone can verify. Their February 2026 Lakegres post says AI agents "think by querying inside their reasoning loops." We fully agree. That's the exact moment. Somebody should decide if this agent may see this column.

Get free Demo Center access Get an instant quote

The short version

Pick DataShield when

An agent is about to read a column with a patient ID in it, say. You need the platform to say no, before the row moves. Not flag it later.
Someone will one day ask you to prove the access log was not edited. An auditor, an examiner, or Article 12 of the EU AI Act. Run the verifier and see what the answer looks like.
You need to pull an agent's mid-session access. The very next tool call should fail.
You just want a price before a sales call. Ours is published.

Pick Onehouse when

Your storage and compute bill is the thing that really hurts. That's the problem they were built to solve. They publish benchmarks to back it.
You want one physical copy of a table, readable as Hudi, Iceberg, or Delta, all at once. XTable is theirs. It's open source. Nobody else has that pedigree.
You run at real scale, across AWS, GCP, and now Azure too. You need ingestion, compaction, and a Spark runtime, managed for you.
SOC 2 Type II and PCI need to be on the table this quarter. They have both. We do not.

Bottom line: Onehouse decides where your data lives, and how fast it moves. DataShield decides which agent may touch it, and keeps proof of the decision. Those are two different jobs. Running both is just the normal answer.

Feature by feature

Competitor cells describe what Onehouse's public site and blog say. We use the date above. If we got something wrong, email support@myorg.ai. We'll fix it and credit you.

What matters	DataShield	Onehouse	Edge
Lakehouse storage and compute	Simply not our job. Ontology ingests files and streams. Think S3, Azure Blob, GCS, SFTP, and SMB, all of them. It then snapshots to Parquet. It queries with DuckDB, over golden views. Those views stay masked, always, no matter what. That's a dataset platform, not a petabyte lakehouse, at all.	That's the whole product, really. Managed Hudi, Iceberg and Delta tables. Plus a Spark runtime, compaction and clustering. All of it sits inside your own cloud account.	◇
Table format interoperability	We just do not translate table metadata. We only read and write Parquet.	Apache XTable, which they themselves created and donated. One single physical dataset, readable as three separate formats. That's really good work.	◇
Sensitive field classification	129 built-in classes cover PII, PHI, financial data, and secrets, all told. That includes all 18 HIPAA Safe Harbor identifiers. Plus eight non-US national ID formats too. We use regex. Plus checksum checks, column-name lexicons, and anti-pattern flags, all of it. No model at all. Results stay fully repeatable, from a config digest.	We found no field classification in their public docs. Their own March 2026 permissions post names PII masking. It's their reason for row-level rules. Those are still listed as coming soon. Not here yet.	◆
Tokenization	Deterministic, join-preserving, vault-reversible tokens, applied at ingest. We also generalize quasi-identifiers, every time. Dates become year, decade or age band. ZIPs become just 3 or 4 digits. Phones, SSNs, and emails all get partial masking. Each column gets its own cardinality-reduction score. We keep detokenization privileged, tenant-scoped, and logged.	Just not vocabulary they use. Their answer to sensitive data is simply who may read the table.	◆
Access control	Each checked tool call passes a scope ceiling. It also carries an access tier. It also gets its own revocation re-check, before dispatch. It fails closed, always. Golden views mask on read. That's true no matter how you set up the deploy.	OneSync Permissions syncs database-level and table-level grants. It covers OneLake, and Glue with Lake Formation. Plus Unity Catalog, and Snowflake Horizon. That's useful, and honest. Column-level and row-level rules stay named, simply, as coming soon.	◆
Audit evidence	SHA-256 hash chain with Ed25519-signed checkpoints. The checkpoints are themselves chained. Verification names the failure: tampering, insertion, deletion or truncation. Try the verifier.	You can audit the permission sync history, in the Onehouse console. That's just a change log, not tamper evidence. We found no cryptographic chain at all.	◆
Break-glass	Scoped, time-boxed emergency access, just for agents. It auto-revokes, on its own. It needs its own step-up too. It can't be quietly deleted from the log, ever.	Simply not described in their public docs.	◆
GDPR erasure	Crypto-shred of per-subject key material. Plus ISO 27560 consent receipts, both at once. HMAC commitments cover actor identities, not names. The chain still checks out, even after a subject is gone.	Nothing public at all, on this. Erasing one person from Hudi or Iceberg history is hard. It's worth asking them how they do it.	◆
MCP and agents	Native MCP sits on Auth, Ontology, Corpus and Lighthouse. That's more than 200 MCP tools, in all. Tool tokens always carry scope ceilings. We meter every call. Each call ties right back to the agent. We seal that decision into the chain, always.	Lakegres gives agents a Postgres-compatible endpoint, right into lakehouse tables. They also market a separate Spark AI agent, for debugging. We found no MCP server at all. We found no agent authorization layer either.	◆
Low-latency serving	DuckDB over Parquet works well for analysis. It's good for agents reading checked datasets too. We publish no latency benchmark of our own. Treat this row as ours, ours alone, to prove.	Lakegres, February 2026: a Postgres-compatible serving layer. It claims a 95% latency cut on point lookups. That's over a 1 TB TPC-DS table. Built just for agent query loops.	◇
Deployment	Self-hosted, right in your own cloud or data center. Or on a dedicated single-tenant server we run for you. Docker images cover Auth, Ontology, Corpus, and Lighthouse. A signed deploy manifest, and Guardian checks it. Ed25519 audit-signing keys stay right on your instance. They sit in a key directory you fully control. Kid-keyed rotation always fails closed, on an unknown key. KMS or HSM custody is a built seam in Auth, not a shipped setup yet. HMAC tokenization keys sit in your own setup today. Or they derive from your machine key. Not in a KMS. Not yet, anyway.	Management services run on a data plane. It sits right in your own cloud account. They state, plainly: no data leaves the trust boundary of your private networks. AWS, GCP and Azure, plus AWS Marketplace.	◈
Maturity signals	Auth, Guardian, and Lighthouse are all live now. Guardian and Lighthouse have both run since April 2026. SOC 2 isn't certified yet, and we say so, plainly.	Founded, in fact, by the creator of Apache Hudi. A $35M Series B in June 2024, led by Craft Ventures. SOC 2 Type II since 2023, and PCI since 2024. A whole logo wall, with Uber, Robinhood, and ByteDance on it.	◇
Pricing	Published model, scoped instant quote, no sales wall.	Quote only, no listed price. Their own pricing page returned a 404, when we checked. The front door here is just a Free Test Drive.	◆

◆ DataShield leads◇ Onehouse leads◈ comparable

Onehouse claims come from onehouse.ai and the Onehouse blog. Last checked 13 September 2026. We link the posts below, not from memory.

Three things you get here that you won't get from a managed lakehouse

Proof that survives an audit

A log an admin can edit just proves nothing. Ours is a hash chain, with signed checkpoints, always. The verifier tells you what broke. Not just that something did. That's the property EU AI Act Article 12 and HIPAA §164.312(b) reviewers care about. Try it in your browser, no signup.

Authority that can change mid-flight

An analyst resigns, say, on a Friday afternoon. Their agent is 20 minutes into a 40-minute job, still running. With DataShield, we re-check the next checked tool call against current access. It fails closed. A table grant that syncs on a schedule just doesn't do that. How Auth does it.

Columns that know what they hold

Before you can protect a field, you first have to know what it is. Is it an MRN? We label columns against 129 classes. Then we go tokenize or generalize the ones that need it. The catalog stores no column values, by default, ever. See the catalog.

Where Onehouse is genuinely stronger

Let's just be fair about the gap. Onehouse ships storage and compute, at a scale we simply don't touch. Their own table optimizer, their Spark runtime, and their ingestion pipelines. All of it has run against 350 TB a day. That's by just a single customer, by their own account, so far. They created both Hudi and XTable. They gave that whole interoperability layer away, free. That's a really costly thing to do. It buys them real trust, with data engineers. They hold SOC 2 Type II and PCI. We hold neither one yet. We're not going to dress that up, at all. Do you want an open lakehouse in your own cloud account? Just go buy theirs. Our catalog scans PostgreSQL today, not Iceberg tables. That limit is a real one, no question.

Here's the honest push-back, then. Their two 2026 launches both reach for our lane. Both of them stop short of it. Lakegres exists because agents query in a loop. It just makes those queries fast. Nothing in it asks whether this agent, right now, may read this column. Nothing writes a record an examiner can check. OneSync Permissions is the honest one. It admits access is a product problem. It syncs grants at the database and table level. It lists column-level and row-level rules as coming soon. PII masking is the example they give. A table grant is simply too blunt, for an agent. Agents just don't need a whole table. They need three fields. For eleven minutes. Under a rule you can show someone later.

Questions worth asking both of us

These are the questions we would want answered. That's if we were the ones buying. Ask them on every call, ours included.

Can you cryptographically prove an audit log entry wasn't deleted?

DataShield: yes, it can. Each record commits to the one right before it. Checkpoints are Ed25519-signed, and chained, always. Verification tells deletion apart from truncation, and from tampering. Run it against a sample chain at /verify. Onehouse: their console shows permission sync history. That's a useful record, sure, but not tamper-evident. We found no chain, and no signature scheme, in their public docs. Just ask them what stops an admin from editing that history.

What happens to a revoked agent mid-session?

DataShield re-checks access on each checked tool call. Revocation lands right on the very next call. Onehouse works through catalog grants. Those sync across OneLake, Glue, Unity Catalog and Snowflake Horizon. We just couldn't find a sync interval in their docs. Nor a mid-session behavior. Ask how long a revoked identity keeps working while the grant spreads out.

How does GDPR erasure interact with the audit trail?

DataShield crypto-shreds the per-subject key material. Then it issues an ISO 27560 consent receipt. HMAC commitments cover actor identities in the chain. The evidence still checks out once the subject is gone. Onehouse publishes nothing on erasure. This matters even more on a lakehouse, than most places. Hudi and Iceberg both keep history on purpose. Ask them how one person disappears from table history without breaking time travel.

Is DataShield a lakehouse? Do we drop Onehouse?

No, and no, plainly. We simply don't manage Iceberg tables. We don't run Spark, either. There's no TPC-DS number at all, to wave at you. Our catalog provider is PostgreSQL today. We've named Snowflake, Databricks, BigQuery and S3 as next. None of those are built yet. So keep the lakehouse. Check the datasets agents actually query, with us.

Lakegres already serves agents at database speed. What's missing?

Speed, not judgement, plain and simple. A Postgres-compatible endpoint answers the agent's question quickly. It just doesn't know that column 7 is an MRN. It doesn't swap it for a token. It doesn't check that this agent still has access. It leaves nothing at all an examiner can verify. Gartner expects most unauthorized agent transactions through 2028 to be internal policy violations. Not attacks. Speed just makes those faster too.

Does DataShield have SOC 2?

Not yet, and we won't imply otherwise. Onehouse does, and PCI too. That's a fair enough point against us. What we offer instead: a public threat model. Plus a verifier anyone can run. Plus source escrow, in design-partner terms. That way a small vendor isn't a single point of failure. Auth is live. Guardian and Lighthouse have been live since April 2026. Details on the security page.

Onehouse's own positioning: "One Data Lakehouse. Any Cloud." and "Open Data Infrastructure in Your Own Cloud Account", with a Free Test Drive, as the entry point, always free. - onehouse.ai, 13 Sep 2026
Lakegres: "a low-latency serving layer on top of open lakehouse tables" with a Postgres-compatible endpoint, claiming a 95% latency reduction for point lookups on a 1 TB TPC-DS table, built because "AI agents think by querying inside their reasoning loops." - Onehouse blog, 17 Feb 2026
OneSync Permissions syncs database-level and table-level grants across Microsoft OneLake, AWS Glue with Lake Formation, Databricks Unity Catalog and Snowflake Horizon. Onehouse lists column-level and row-level permissions, including PII masking, as coming soon. - Onehouse blog, 13 Mar 2026
Deployment model: management services run on a data plane inside your cloud account, and "no data ever leaves the trust boundary of your private networks." - onehouse.ai/product, 13 Sep 2026
$35M Series B led by Craft Ventures with Addition and Greylock, announced alongside the quest for "the most open and interoperable data platform." - Onehouse blog, 26 Jun 2024
Onehouse achieved SOC 2 Type II certification in August 2023. Onehouse open-sourced OneTable, now Apache XTable, in November 2023. - Onehouse blog, 29 Aug 2023 and 15 Nov 2023

Other head-to-heads

Same market

Get free Demo Center access

You've seen the proof

Ready for a number? Scope your deployment and we'll price it against your own economics.

Get your quote →