Integrations¶
sutura connects to three kinds of system. A catalog supplies the definitions: models, joins and metrics. A metrics serving layer serves certified metrics to many tools. A data system holds the data and runs the queries. Each adapter has one page. Kinds and settings lists the keys that every catalog and every data system reads.
Semantics¶
A catalog serves one governance model. In multi-player governance, many owners keep one reviewed source of truth in a shared catalog: see the multi player example. In single-player governance, one owner keeps the files in the repository: see the single player example.
Metadata platforms¶
The catalog reads from a metadata platform over its API.
-
DataHub
Recommended Catalog · multi-player governance
Read models, joins and certified metrics from a shared DataHub.
-
OpenMetadata
Catalog · multi-player governance
Read tables, descriptions and joins from a shared OpenMetadata.
Databases¶
The catalog reads from a database.
-
RDBMS dictionary
Catalog · multi-player governance
Read table descriptions from a documentation view in PostgreSQL or Oracle.
Files¶
The catalog reads from files that you keep in git.
-
Markdown catalog
Catalog · single-player governance
Write the whole model as markdown files and review it in git.
-
OKF
Catalog · single-player governance
Read table structure and descriptions from Frictionless Table Schema files.
-
Data Contract
Catalog · single-player governance
Read tables, columns and joins from Open Data Contract Standard v3 documents.
-
Wren
Catalog · single-player governance
Convert a WrenAI manifest into a markdown catalog that you review.
Metrics serving layers¶
A metrics serving layer, such as Cube, serves and caches each certified metric for BI tools, REST clients and other established tools. If your organization runs one, sutura reads the metrics from it, so agents and BI tools get the same number. If only agents need the metrics, sutura computes them from the catalog definitions, and you need no serving layer. sutura itself keeps no result cache, for security reasons.
-
Cube
Metrics serving layer
Read the cubes and their dimensions from a Cube deployment.
Data¶
A data system runs in one of two identity modes. With shared-service-user, every caller's query
runs as the one identity that the deployment declares. With secure-impersonation, each caller's
query runs as that caller's own identity at the source.
Databases¶
The data system is a database.
-
BigQuery
Recommended Data system shared-service-user secure-impersonation
Run questions as one service account or as each caller's own account.
-
ClickHouse
Recommended Data system shared-service-user secure-impersonation
Run questions over a ClickHouse server through its HTTP interface.
-
DuckDB
Data system shared-service-user
Run questions over one DuckDB database file, opened read-only.
-
Oracle
Data system shared-service-user secure-impersonation
Run questions over an Oracle Database as one declared user, or as each caller with their own token.
-
PostgreSQL
Data system shared-service-user
Run questions over a PostgreSQL database as one declared role.
Storage¶
The data system reads files.
-
DataFusion (files)
Data system shared-service-user
Run questions over Parquet, CSV and NDJSON files, inside the sutura process.
Identity mode of each data system¶
| Data system | Identity mode |
|---|---|
| DataFusion (files) | shared-service-user only |
| DuckDB | shared-service-user only |
| BigQuery | shared-service-user and secure-impersonation |
| PostgreSQL | shared-service-user only |
| ClickHouse | shared-service-user and secure-impersonation (EXECUTE AS) |
| Oracle | shared-service-user and secure-impersonation (OAuth 2.0 token) |
Identity¶
-
Inbound identity
Identity
Verify who is asking with a token from your identity provider or an assertion from a gateway.