Governed from the first query.
Nothing to connect yet? Download and take the demo tour
Sounds too good to be true? Here's how it works →
# psql speaks to Provisa as if it were Postgres — on port 5439
psql -h localhost -p 5439 -U analyst
# One SQL query, joined across Postgres, Mongo, and Elasticsearch
SELECT c.name, o.total, t.trace_id
FROM customers c
JOIN orders o ON o.customer_id = c.id
JOIN queries t ON t.actor = c.email
WHERE o.total > 1000;# The per-role schema, over plain HTTP
POST https://provisa.internal/graphql
# The same question — relationships are fields, not joins
query BigOrders {
orders(where: { total: { gt: 1000 } }) {
total
customers { name email }
queries { trace_id }
}
}# Neo4j Browser and the official drivers, over Bolt
bolt://localhost:7687 # database: provisa_analyst
# The same question — sources are labels, relationships are edges
MATCH (c:Customer)-[:PLACED]->(o:Order)
MATCH (c)-[:RAN]->(t:Query)
WHERE o.total > 1000
RETURN c.name, o.total, t.trace_id# No new language. The endpoints are generated from the model.
curl -G https://provisa.internal/data/jsonapi/orders \
-H "Authorization: Bearer $TOKEN" \
-d 'filter[total][gt]=1000' -d 'include=customers'
# The same question — JSON back, related rows sideloaded
{ "data": [ { "type": "orders", "attributes": { "total": 1420 } } ],
"included": [ { "type": "customers", "attributes": { "name": "Acme" } } ] }
# The spec is generated too — point a client generator at it
curl https://provisa.internal/data/jsonapi/openapi.json# A .proto generated from your schema — typed RPCs per table
grpcurl -d '{"total_gt": 1000}' provisa.internal:443 \
provisa.orders.OrdersService/Query
# The same question — a typed response, no schema drift possible
message Order {
string id = 1;
double total = 2;
Customer customer = 3;
repeated Query queries = 4;
}One model, three languages, and generated REST if you want none of them. RLS, masking, and approval are already applied on whichever tab you pick. There is nothing to re-implement per protocol.
Provisa is a data kernel: a compiler and runtime for your data control plane. Sources, metrics, ontology and governance from one model. Nothing to keep in sync.
Most requirements fall into six problem types, and they rarely arrive on day one. They land late, on a project that is already behind schedule, and upend it:
AI access
Point Claude or any MCP client at Provisa instead of the database. The OAuth token maps to a role, so the agent gets the same six access-control layers a person does. No invalid join ever runs on your data: roles are governed by default, and opting out is a deliberate grant.
Governed data for AI →App backends
The app needs Postgres, a document store, and two internal REST services in the same response. Declare the relationships once and the API spans all of them, per role, filtered and paginated, in whichever shape your client wants: GraphQL/OpenAPI, JSON:API, or gRPC. No BFF service to maintain.
The interfaces, and the Hasura path in →BI across sources
Postgres, Mongo, Elasticsearch, a Google Sheet, an S3 prefix of extracts, and the SaaS systems the business runs on, Salesforce, ServiceNow, Jira and Stripe among them. Connect the BI tool over JDBC or pgwire and join across all of them, with no pipeline into a warehouse first and no copy in the middle.
All 73 connectors →Data science access
Register the sources once and the whole team queries them from a Jupyter
notebook (%%sql, %%graphql or %%cypher
cells straight into a DataFrame), pandas, Polars, or DuckDB. Arrow Flight streams record batches columnar all the way out, with no
row-by-row serialization and nothing materialized server-side while you
read, and single-source queries route straight to the driver. To train
without PII, point at our auto-generated synthetic data.
Data provisioning
The consuming team writes SQL and gets it back fast: Arrow streams over Flight, typed gRPC, and, past a row threshold, a presigned S3 URL for multi-GB deliveries instead of a timed-out HTTP response. Kafka carries the change notifications, so they pull the delta rather than the snapshot.
How the governance follows the data →Public data
Your database joined by county to NOAA weather, by CVE to CISA's exploited-vulnerability catalog, by LEI to Wikidata's ownership graph, or by NDC to FDA recalls — with no ETL and no pipeline. Every join governed the same way as any other.
See the demos →With one model, closing each of these gaps is a config change, not a rebuild.
73 connectors, 85+ kinds of source, one API
Those are usually four tools, each holding its own description of the same data: a query engine, a metrics layer, a catalog, a policy service. When one changes, the others are wrong until someone catches it. The descriptions drift, and there is no mechanism to keep them in step.
One model: sources, metrics, ontology and governance.
You describe your data once: sources, tables, relationships, who may see what. Everything else is generated from that one description — the APIs, the legal join paths, the governance, and the audit trail. Keep the catalog and lineage tools you have; Provisa publishes to them. Data catalogs that provide a context layer tell an agent what it should do; Provisa enforces what it can do.
One model — what each part covers Every change is versioned, and promoted through environmentsGraphQL, Cypher, and SQL all query the same model and retarget to any source dialect. Domains carve it into namespaces (a domain is the schema a SQL client sees), and governance applies identically across all of them. Add a protocol and the governance follows automatically.
Analytical and transactional flows through the same governed API: cross-source reads fan out through the engine; writes and single-source reads route direct to the driver, sub-100ms.
Single-source queries bypass the engine entirely. Materialized views record the transform that built them, so queries rewrite transparently onto a fresh MV.
Query interfaces & wire protocols
Each language-transport stack needs its own governance integration and its own programmers. Data leaks and exfiltration paths appear at every new surface. A change to the access model now touches every interface point, which becomes its own lock-in: you can't change one thing without changing several.
Each stack also kicks off another endless round of tool selection, vendor selection and standards processes, then procurement, contracts, invoices, renewals, disputes, and the debates between teams over where business logic, security and capabilities should live, which end in building yet more integrations. Start a GraphQL API team, for example, and it grows along exactly those lines. If the goal is a bigger team, that plan works.
Every language and wire protocol here compiles to one IR. Governance is applied once at that IR — a change happens once, and the same rules reach every combination of language, transport, and tool.
The result: your BI dashboards and your application APIs share the same semantics and the same governance.
Per-role schemas with field-level visibility, constrained to registered relationships — valid by construction.
Full SQL across all sources. Single-source queries route direct to the driver, under 100ms.
Graph traversals over the model, under identical governance.
SPARQL 1.1 over the model, with your ontology’s classes and properties as the vocabulary, under identical governance.
Access control, compiled in
When access control is configured per API, every new interface is another integration to get right, and proving to an auditor that no path was missed means checking each one separately. Here access control is compiled into the query plan on every language and every transport. Add a source, a column, or a relationship and every layer applies to it automatically — there is nothing to re-apply per interface. It's one part of governance; where, when and how work runs, and what the data means, are declared in the same model.
Schema browsers only ever see what the role is allowed to see.
Anonymous surface is explicit, never accidental.
Roles reach only the domains registered to them.
Per-table, per-role WHERE injection — inherited recursively.
Regex, constant, or truncate masking with role-based bypass.
Pre-execution ABAC hook over webhook, gRPC, or unix socket.
All six are applied while the query is compiled, not checked against a policy list afterwards. What executes is already the controlled query, so no version of it could have run ungoverned.
Relationships are governed too. A JOIN or a graph traversal is legal only if it matches a registered, approved relationship, so people and agents can explore the whole model while every path stays inside what policy approved. It's a right on the role: a trusted role can be granted the way around it.
Governance, in its complete senseData sources
Every new source usually starts a pipeline project: what to copy, where to land it, how to keep it current. Here, 73 connectors reach 85+ kinds of source where the data already lives, and copying is a declared choice, not a prerequisite. And if a source is unique to you, a code resolver, a Python or Node function, gives it structure as a governed table.
Graph and RDF sources take part in the model like any other. Register REST, GraphQL, gRPC, WebSocket or RSS endpoints as governed tables, and cross-source joins reach them like any table.
Auto-indexing file crawler
One of the 73 connectors behaves unlike the other seventy-two: you register a location, not a table. It walks the tree recursively, finds tabular files and the tables inside documents, and catalogs each table — the shared drive nobody has mapped, the S3 prefix of extracts, the SharePoint site a department has been running on for years.
A local or network folder, an S3 bucket, a SharePoint site, an HDFS path, or an HTTP, FTP or SFTP host: one location, not one table.
It walks the tree to whatever depth you allow and searches every file for tables: a CSV or Parquet file is one; in an Excel workbook it finds the regions of each sheet that look like tables and extracts each; in HTML, Markdown, Word and PowerPoint it extracts the tables the document marks as tables. In documents with links it follows them too, down to the same depth limit.
You pick which of the discovered tables to register, and they land under the same six access-control layers as everything else.
Code resolvers
Code resolvers are the contract for integrating any data source. A Python or Node function returns typed rows, and that function becomes a table: governed like any other, with visibility, masks and row rules applied to what it returns, joinable to the rest of the model, and served on every language and transport. A function that takes a loader gets every key of a join in one call, and filters can reach it as parameters. Its code is pinned by version, commit or hash, so it is promoted with the model.
In production, code resolvers don't sit in the control plane. Provisa builds each one its own container image, with no Docker daemon: the code at its pinned hash and its dependencies on a minimal base, pushed to your registry or downloaded. Run it wherever it belongs, beside the data, on a GPU box or inside another network, and Provisa pairs with it over mutual TLS.
Derived data & your existing stack
A pipeline is a program that ran; to audit one you read code. When the source changes, the pipeline is wrong until someone finds it and fixes it. The only durable record of what happened is the output table and a log line. Declare the dataset instead and the definition is the record.
A pipeline is a program that ran; to audit one you read code. Declare the dataset instead and the definition is the record: column-level lineage, the data version consumed, the rules that produced it. No orchestration DAG.
One registration publishes to OpenMetadata, DataHub, Collibra, Atlan, Apache Atlas, OpenLineage, BigQuery Dataplex and Snowflake Horizon, with lineage stitched on business identity, so re-platforming doesn't reset it.
Bring tables, keys, relationships, and metrics from dbt, Cube, Snowflake, Databricks, and other semantic layers through Apache Ossie. Every imported definition is a proposal you review before it registers.
Governed values resolve over REST or MCP at a semantic address, optionally as of a point in time. Physical URIs are refused, so a citation can't leak a location.
Enterprise-ready
Wouldn't it be refreshing to just try it out, without the hassle? No Docker registry to mirror, no JVM, no root. The embedded profile ships the entire runnable system, precompiled UI included, as a single Python wheel. Regulated and airgapped orgs already trust Artifactory-as-PyPI, so there is no new supply chain to approve.
# One wheel. Everything inside.
pip install "provisa[embedded]"
provisa run
# Federate against your own engine when you want scale-out
export TRINO_HOST=trino.internal
export TRINO_PORT=8080
provisa runYour model, semantics, and governance live above the infrastructure, not inside it. Swap the engine from embedded to Trino, or to your warehouse, or to Databricks when a new CTO brings a new strategy, and the queries and policies don't change. Re-point a table from Oracle to Postgres and consumers never see it move.
We don't lock you in either: your model is portable declarative config, and the SQL it compiles is yours to read, export, and keep.
The full argument — including domains as products, config promotion, and the compute billGet Provisa
Desktop installers for every OS (the macOS app signed and notarized), or pip install the Sigstore-attested
embedded runtime. The whole working system runs on your desktop in about five minutes, with no
Docker, no JVM and no cluster. Launch it and pick the guided demo:
a sample model is already bundled, so you can run SQL, GraphQL, and
Cypher over it before you connect anything of your own.
Prefer not to install anything? Connect your own sources in the browser at
sandbox.provisa.dev.
Free to evaluate, for any size of organization. License terms →
The whole runnable system, precompiled UI included, as a single wheel. Airgap-ready over an Artifactory PyPI mirror: no Docker, no JVM, no root.
# One wheel. Everything inside. (Python 3.12)
python3 -m venv .venv && source .venv/bin/activate
pip install "provisa[embedded]"
provisa run # your data
provisa run --demo # a guided tour on a sample stackEnvironments
Every change is applied by hand in each environment, they drift, and test data is either a risky copy of production or too thin to trust.
Here each environment is a branch of the model. Analysts and developers make changes in their own, merge them back through a request someone approves, and can push to your git repository, so changes go through the release process you already run. Each environment can also carry its own data: production's real rows, a pre-production copy with every sensitive column faked, or generated data for development.
Deploy anywhere
Or are you still waiting for someone to stand up the infrastructure? Everyone gets an isolated environment on their own desktop: no shared dev server to break, and no infrastructure to wait for. From a laptop to a cluster, it's the same platform.
macOS, Windows, and Linux installers (the Linux installer covers Linux and NixOS), each with a one-click demo build that boots a sample stack. The macOS app is signed and notarized; for a signed install on Linux or Windows, pip install provisa installs the Sigstore-attested PyPI package.
pip install "provisa[embedded]" — the whole system, precompiled UI included. Airgap-ready.
A production chart deploys the control plane, workers and engine, and the query tier scales horizontally.
Modules for AWS, Azure, and GCP stand up a VM or cluster deployment end to end.
Questions
Neither. Provisa is a semantic and governance layer that runs on an engine you choose: Trino, DuckDB, ClickHouse, Postgres, Snowflake, Databricks, BigQuery, or the embedded DuckDB engine in the box. Your warehouse becomes a replaceable execution engine, not the place your semantics live.
How it works in depth
Starburst is a query engine; Provisa sits above one and can use Starburst as
its engine. Denodo is the closest comparison, in the same category: Provisa adds GraphQL and Cypher as peers to SQL, nine wire
protocols including pgwire and Bolt, engine choice, and a deployment that
starts at one pip install.
Data mesh was a governance model, in its most complete sense, and never had a runtime. Provisa is that runtime: each domain owns its namespace and its ODPS data products over the systems it already runs, and where, when, how, for whom and with what meaning data is processed is declared once and compiled into every query, on the engine you already have.
Data mesh, with a runtimeYes. Point the converter at your Hasura v2 metadata directory and it emits a Provisa config: sources, tables, per-role permissions as row-level security, relationships, remote schemas, actions, event triggers, and cron triggers. Anything it can't map cleanly is reported as a warning rather than dropped.
The migration pathAn MCP server, over stdio or remote Streamable HTTP, exposes governed tables as tools. The OAuth token maps to a role, so every agent call passes the same six access-control layers as a human query, and traversals are limited to registered relationships. Agents get no bypass and there's no second policy to keep in sync.
Governed data for AIThe embedded profile ships the entire runnable system, precompiled UI included, as a single Python wheel. Regulated orgs already trust Artifactory-as-PyPI, so there's no Docker registry to mirror, no JVM, and no root required. Its dependencies are locked with hashes in the repository.
You keep it. Provisa is a handful of primitives (domains, tables, relationships, masking, views) compiled deterministically. The model is portable declarative config held in git, and the SQL it compiles is yours to read and export. The semantics you write don't die with the tool.
Our position on lock-inOne governed path for analytical, application, and human data movement.