Govern every source from one place.
Datattach is the single access layer in front of all your data. Define who can see what once — role-based access, row-level security, and column masking — and it's enforced on every query, from every tool.
SELECT c.name, c.region, c.email, o.total
FROM postgres.crm.customers c
JOIN snowflake.sales.orders o ON o.customer_id = c.id
ORDER BY o.total DESC;| name | region | total | |
|---|---|---|---|
| Acme Corp | US-East | ops@acme.com | $48,200 |
| Globex | EU-West | data@globex.eu | $36,900 |
| Initech | US-West | bi@initech.com | $21,400 |
| Umbrella | EU-North | it@umbrella.eu | $12,750 |
| Globex | EU-West | NULL · masked | $36,900 |
| Umbrella | EU-North | NULL · masked | $12,750 |
one cross-source query — toggle the persona
Single access layer with role-based access controls
Every source sits behind one connection, so access is defined in one place — not re-implemented per database. Grant access by role, scope it down to the catalog, schema, or table, then layer row-level security and column masking on top. It's enforced at query time, uniformly, for everyone.
- Role-based groups — grant by role, not one person at a time
- Catalog, schema, and table permissions in one place
- Row-level security and column masking layered on top
- One layer for BI tools, MCP agents, and SQL clients alike
Who can access this table
- Full access
Admin
Every connected catalog
- Read + manage
Data Owner
Catalogs they own
- Read · RLS · mask
Analyst · sales-eu
customers, orders
Query history
Every statement that runs through the connection is captured automatically — who ran it, from which tool, which sources it touched, and how long it took. History lives in its own lakehouse, so looking at it never loads your production sources.
- Every statement captured — who, what, which sources, how long
- Filter by user, tool, source, or latency
- Raw events queryable in SQL via platform.query_events
- Stored apart from your sources — auditing never touches them
1,284
Queries today
37
Active users
240 ms
p50 latency
Recent queries
- sam@acme.io postgres + snowflake Tableau 312 ms
- dbt-build mysql → redshift dbt 4.1 s
- dana@acme.io iceberg DBeaver 198 ms
Permissions auditing
Because access is defined in one layer, you can see the whole picture. Ask who can reach any table and get a straight answer — each principal's effective access and the group or grant that resolves it — so over-broad access and unintended exposure surface before they become a problem.
- See exactly who can reach any catalog, schema, or table
- Trace why — the group or grant that resolves the access
- Spot over-broad access and unintended exposure early
- Answer “who can see this?” without spelunking through configs
Who can read postgres.crm.customers?
- Full
Dana · Admin
direct grant
- Read · RLS · mask
Sam · Analyst
via sales-eu group
- No access
partner@ext.com · External
not granted
One access layer for every source.
Toggle a persona in the live demo to watch row-level security and masking apply, then book a walkthrough against your own sources.