Provisa is a data kernel: a compiler and runtime for building your data control plane. Sources and engines plug in as drivers. You declare your data model once, and every surface reads it, from psql and Tableau to GraphQL, Cypher, REST, gRPC and Arrow Flight. Each one has governance compiled in. Your ontology is grounded to the data, and agents work through it, using only approved terms that reach a table their role can read. Data federation queries each source where it lives, so there is no copy left to drift.
Connect Postgres, Snowflake and Salesforce.
Query with SQL, GraphQL or your AI agent.
In 5 minutes.
Nothing to connect yet? Download and take the demo tour
Skeptical? Read how it works →
# psql talks 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, with relationships as fields
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, with sources as labels and relationships as edges
MATCH (c:Customer)-[:PLACED]->(o:Order)
MATCH (c)-[:RAN]->(t:Query)
WHERE o.total > 1000
RETURN c.name, o.total, t.trace_id# The endpoints are generated from the model, so there's no new language
curl -G https://provisa.internal/data/jsonapi/orders \
-H "Authorization: Bearer $TOKEN" \
-d 'filter[total][gt]=1000' -d 'include=customers'
# The same question, returning JSON with related rows sideloaded
{ "data": [ { "type": "orders", "attributes": { "total": 1420 } } ],
"included": [ { "type": "customers", "attributes": { "name": "Acme" } } ] }
# The spec is generated too, so you can point a client generator at it
curl https://provisa.internal/data/jsonapi/openapi.json# A .proto generated from your schema, with typed RPCs per table
grpcurl -d '{"total_gt": 1000}' provisa.internal:443 \
provisa.orders.OrdersService/Query
# The same question, with a typed response, so the schema can't drift
message Order {
string id = 1;
double total = 2;
Customer customer = 3;
repeated Query queries = 4;
}These all query the same model: three languages, plus generated REST if you want none of them. RLS, masking, and approval are already applied on whichever tab you pick, so you don't re-implement them per protocol.
Federation, metrics, ontology and governance from a single model. Nothing to keep in sync.
Built from data architecture and governance in regulated industries, with the methods of devops that run through operating systems, Kubernetes, Terraform and Helm, and the compiler design of LLVM. You declare a small set of primitives and a control plane keeps them true, so you assemble a solution instead of writing one, and any code you do need sits behind a contract. Where the design comes from.
Most requirements are some combination of six problem types, and they rarely arrive on day one, together. They land late, on a project that is already behind schedule, and they 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, whether that's GraphQL/OpenAPI, JSON:API or gRPC, and you have 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 the result fast, as Arrow streams over Flight or typed gRPC. Past a row threshold it gets a presigned S3 URL for the multi-GB delivery, where an HTTP response would time out. Kafka carries the change notifications, so the team pulls the delta and skips the snapshot.
How the governance follows the data →New or changing sources
Join your database 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. Those joins are governed like any other. When a source moves or its schema changes, you remap it once, and every API, dashboard and agent keeps working.
See the demos →Because everything reads one model, each of these is a config change instead of a rebuild.
Each of those jobs usually brings its own tool, and each tool keeps its own copy of what your data means. The catalog has a glossary. BI has metric definitions. Every API checks access its own way, and the agent gets its own context. When one copy changes, the rest are wrong until someone catches it. More tools mean more copies, and each copy drifts on its own.
One model for federation, metrics, ontology and governance.
You describe your sources, tables, relationships, terms and access rules once. The APIs, the legal join paths, the governance and the audit trail all come from that one description. Your tools discover the live model, so there is no SDK to generate, version or upgrade. You write what you mean, and Provisa owns making it run correctly. If your catalog meets other objectives you have, keep it; Provisa will push to it. Data catalogs that provide a context layer tell an agent what it should do. Provisa enforces what it can do.
IDC has tracked the “data control plane” as an architecture and a vendor market since 2021 (Market Glance 1Q23, 1Q25).
What each part of the model covers Every change is versioned, and promoted through environments73 connectors and 85+ kinds of source behind one API
GraphQL, 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 work goes through the same governed API. Cross-source reads fan out through the engine, and writes and single-source reads go straight to the driver in under 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, and governance is applied once, at that IR. You make a change in one place, and the same rules reach every combination of language, transport and tool.
Your BI dashboards and your application APIs end up with the same semantics and the same governance.
Per-role schemas with field-level visibility. Only registered relationships appear, so a query is 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, with nothing to re-apply per interface. Access control is 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.
Anything anonymous is declared, so nothing goes public by accident.
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. The guard is a right on the role, so you can grant a trusted role the way around it.
What governance coversData 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 you copy data only when you declare a copy. 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 instead of a table, and it walks the tree recursively, finds tabular files and the tables inside documents, and catalogs each table. That might be the shared drive nobody has mapped, the S3 prefix of extracts, or the SharePoint site a department has been running on for years.
Give it a local or network folder, an S3 bucket, a SharePoint site, an HDFS path, or an HTTP, FTP or SFTP host.
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. It's governed like any other, with visibility, masks and row rules applied to what it returns, you can join it to the rest of the model, and it's 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 image holds the code at its pinned hash and its dependencies on a minimal base, and it's 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.
The definition records the column-level lineage, the data version consumed and the rules that produced the dataset. There's no orchestration DAG to run.
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
You can try this one with no Docker registry to mirror, no JVM and 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.
# The whole system in one wheel
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 →
You get the whole runnable system, precompiled UI included, as a single wheel. It installs in an airgap over an Artifactory PyPI mirror, with no Docker, no JVM and no root.
# The whole system in one wheel (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. The same platform runs on a laptop and on a cluster.
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]" installs the whole system, precompiled UI included, and works in an airgap.
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 data kernel that builds your data control plane and runs it 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, and your semantics live in the model.
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 data federation comparison. 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 described governance in full 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 AISomewhere in its reasoning, the agent turns your words into a query, and it guesses what the words mean from table and column names. Provisa lets you define the terms your organization uses, bind them to the data they mean and have a steward approve them. An agent can then find data through approved, grounded terms, and its answer cites the term, the route and the data it used.
Shared meaning for agentsThe 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-inAnalytical, application and human data movement all take the same governed path.