Built to be trusted with all of your data.

Datattach sits between your team and every database you own. Here's the architecture that earns that position — and straight answers to the questions your security review will ask.

We didn't reinvent the hard parts. Datattach assembles and operates the open-source standards you already trust — Trino, OPA, dbt, dlt, and Iceberg — into one governed connection.

The engine — Trino

A managed Trino core federates your queries. Single-source work pushes down into the source database; cross-source joins run in the engine, moving only the rows they need.

The policy gate — OPA

Every statement is checked by Open Policy Agent inside the query path — catalog and table grants, row filters, column masks. Not in the client, not in a layer a BI tool can skip. Fail-closed.

The ingest runtime — dlt

SaaS extraction is declared in dbt and executed with open-source dlt, landing tables in a warehouse you own. No staging copy inside Datattach — the landed table is the only copy.

The audit trail — Iceberg

Every statement is recorded to your tenant's Iceberg audit lakehouse — who ran it, which sources it touched, how long it took — kept apart from your sources, and queryable by your team in plain SQL.

Tenant isolation

Isolation that scales with you

Every plan starts with policy-enforced isolation on every statement. When your requirements harden, the infrastructure moves with them.

1 Standard

Shared cluster

Tenant catalogs are namespaced, every statement passes the policy gate scoped to your tenant, and a user belongs to exactly one tenant — enforced at the database level, not just in application code.

2 Enterprise

Dedicated cluster

Your own query cluster — no shared compute, no noisy neighbors, and a blast radius that ends at your tenant.

3 Enterprise+

Your VPC

The entire platform runs inside your own cloud account. Your network, your keys — Datattach operators have no access at all.

See how the tiers compare →

Security posture

The questions, answered up front

Sign-in, governed by your IdP

OIDC single sign-on with per-tenant enforcement, and SCIM provisioning so joiners and leavers sync from your IdP automatically. No shared service accounts — every query is attributable to a person or a named agent. Per-identity BI passthrough is in final testing and planned for launch.

Access rules in the engine

Grants down to catalog, schema, and table, plus row-level security and column masking — evaluated inside the query path on every statement, identically for every tool.

Encryption everywhere

TLS in transit, encrypted storage at rest. Source credentials are encrypted, decrypted only to open connections, and never appear in logs, browsers, or query events.

EU-hosted, sovereignty by choice

Datattach is an EU company and runs on AWS in the EU today. As we add regions, data residency becomes something you configure — not something we decide for you.

What we store (and don't)

Query results stream to the client and are never persisted. What we keep: the audit trail — user, timing, sources touched, the SQL text itself — and the definitions of views you build through us. SQL text, never your rows.

AI agents on the same leash

The MCP server authenticates agents as identities. They get the same row filters and column masks as the person who owns them, and every agent query lands in the audit trail.

Bring us your security review

Datattach is an EU company on EU infrastructure, GDPR alignment is table stakes, and SOC 2 is on our roadmap. We're early — which means your security team gets direct answers from the people who built the platform, not a compliance portal.

Book a security walkthrough →

The catch?

Questions you should be asking

Does my data get stored on your servers?

No. Data stays in your sources and query results stream through to the client. What we persist is the audit trail: query metadata — user, timing, sources touched, and the SQL text itself, which can include literal values written into a query. It's stored apart from your sources, scoped to your tenant, and queryable by your own team in plain SQL. We also keep the definitions of views you build through Datattach — again, SQL text. Your rows are never stored.

How are tenants isolated from each other?

Catalogs are namespaced per tenant, and every statement passes the policy gate, which scopes access to your tenant's catalogs before anything executes. A user belongs to exactly one tenant — enforced at the database level. If you need more than logical isolation, Enterprise runs you on a dedicated cluster and Enterprise+ moves the whole platform into your VPC.

Can Datattach staff see my data?

There's no in-product way to: no impersonation feature, no admin query console, no support backdoor. If support ever needs to see what you see, you create an account for us and grant it access through the same catalog, row, and masking controls as any other user — and revoke it the moment we're done. For teams that need a hard guarantee rather than a policy, Enterprise+ runs the platform inside your VPC, where our operators have no access.

Where do my database credentials live?

Encrypted at rest on the server, decrypted only to open connections to your source. They're never sent to browsers or clients, and they never appear in logs or query events.

Why not just run Trino myself?

You genuinely can — Trino is an excellent open source SQL engine, which is exactly why we use it. What you're taking on is an always-on cluster bill, version upgrades, per-connector tuning, and wiring up access control policies yourself. Datattach does all that for you — all while adding a bunch of features not available in stock Trino:

MCP access
SaaS ingestion baked into your dbt project
Dramatically faster dbt writes
BI tool SSO identity passthrough for end-to-end access controls

What happens if I leave?

Nothing dramatic — that's the point of an engine that doesn't move your data. Your data never left your sources, and your queries are standard SQL. Disconnect the catalogs and everything still lives where it always did.