Querying
Read managed tables from workflows, notebooks, and raw SQL — same authorisation, same column masking, same audit trail.
There are three ways to read a managed table. All of them go through the same authorisation layer, the same column-masking pipeline, and the same audit trail.
From a workflow
Workflows use the scrydon:tables product (see Vendors → Scrydon). Common tools:
| Tool | Purpose |
|---|---|
get-schema | Returns the table's columns, types, classifications, and the mask strategies applicable to the caller |
query | Run a structured query (filters, sorts, paging) — typed result set |
query-sql | Run a SQL string — for cases where structured query isn't expressive enough |
write | Append / replace / upsert / delete |
delete | Remove the table (workspace-admin grant required) |
Workflows always read against the execution grant — the actor for governance purposes is the user who triggered the run, not the workflow itself.
From a notebook
Marimo notebooks connect to the same managed-table surface. The notebook session is authenticated against the user who opened it, so reads apply that user's masks and filters.
From raw SQL
Workspace admins and analysts can issue raw SQL through the Analytics UI's SQL surface. The query is parsed, rewritten to apply masks and row filters, and executed against the warehouse.
Restrictions on raw SQL:
- Cross-tenant queries are rejected (the rewriter only allows tables in your organisation's catalogue).
- DDL (
CREATE,ALTER,DROP) is rejected — table lifecycle goes through the catalog API. - Queries that would expose denied columns fail with a permission error (not a silent NULL).
What you don't see
Three things are deliberately invisible:
- Other tenants' data. Even with admin grants, you can't see another organisation's tables.
- Internal system columns. Implementation columns used by the warehouse aren't exposed to SQL.
- Masked column values without the right role. A
redactmask shows[REDACTED]; anullmask showsNULL; adenymask fails the query.
Want to know whether a column is masked for you? Call get-schema — it returns the mask strategy applicable to the calling actor for each column.
Performance
The warehouse is OLAP-optimised (columnar storage, vectorised execution). For most analytical queries — aggregates, joins, scans — it's fast. For point lookups on huge tables, prefer a structured query with a primary-key filter.
Audit
Every read emits a RESOURCE_ACCESS event. See Audit logging.
Related
- Managed tables — the lifecycle these queries run against.
- Classification & masking — what the policies do to your query.
- Marimo notebooks — Python-driven querying.