The claim
Connect Postgres, Snowflake and Salesforce. Query with SQL, GraphQL or your AI agent. In 5 minutes.
We mean that literally. Point Provisa at your sources, describe how they fit together, and you have a governed API across every source. The Start here demo walks through all five minutes on a sample dataset.
The mechanism
Provisa is a data kernel: a compiler and runtime for building your data control plane.
The primitives are sources, tables, relationships, terms, roles, capabilities, grants, scope, products, and contracts. Declare them and the whole governed API follows: the query endpoints, the legal join paths, the access rules, and the audit trail.
Every language compiles to one IR. Governance is applied there and pushed down into the native query your engine runs. A GraphQL query, a SQL statement and a Cypher traversal all pass through the same governance point before anything reaches your data.
Provisa compiles each request and hands it to your engine. Results stream back. It scales horizontally and vertically, and your engine does the heavy compute.
It is built the way an operating system is built, on the same philosophy as an OS kernel and its drivers. Source drivers, engine drivers and secrets drivers plug in and swap without reinstalling. Command bindings are the compatibility layer that answers other tools’ calls: APOC for Neo4j tools, catalog functions for SQL clients, fields in GraphQL, tools in MCP. BI tools, notebooks, agents and apps are clients connecting over standard protocols. Provisa drives your systems; it does not run on them and never becomes their engine.
Where the design comes from
Provisa's design comes from two places. Devops supplied the method, and data disciplines and regulated industries supplied the problems to solve and the bar the answer has to clear.
Both aim at the smallest possible set of primitives with which you can define, secure and operate a data estate.
The method, from devops
Operating systems, virtual machines, Kubernetes, Terraform and Helm share a habit. Faced with a problem, they first ask which primitives would let the solution be assembled instead of written. Code stays valuable, behind contracts, for the work the primitives can't express.
Infrastructure has already made this move. Servers used to be built by hand and kept alive by scripts; today you declare them, and a controller reconciles what runs with what you declared. Data is where infrastructure stood before Kubernetes and Terraform. Each of those tools gave Provisa one idea, and so did a compiler toolkit, LLVM.
- Operating systems and virtual machines: a small kernel that enforces isolation. The primitives listed under The mechanism make up Provisa's kernel. The kernel enforces isolation and permissions, so governance is compiled into every request and no application has to write it again. Sources and engines are drivers. You plug them in, and you can swap one without touching the model above it.
- Terraform: declare the desired state, and plan before you apply. Your model lives in git branches. A change shows up as a diff, with an impact analysis of everything it touches, and it is approved before it moves from one environment to the next.
- Kubernetes and Helm: a control plane that reconciles. What you declared and what is running are kept apart. The model store holds the declaration; the state store holds what the runtime is doing. The runtime keeps converging replicas, freshness and materialized views toward the model, so what you serve follows what you declared.
- LLVM: many front ends, one intermediate form, many back ends. GraphQL, SQL, Cypher, SPARQL, gRPC and MCP each compile to one intermediate form. Governance, materialized-view rewrites and optimization run as passes over it, once, for every language. The engines are the back ends that run the result. This is why one compiler can speak every language.
The problems and the bar, from data and regulated industries
Dataops, data management, data architecture and data governance decided which primitives the kernel needed. Years of that work are why governance, lineage and stewardship are part of the kernel itself.
Highly regulated industries set the bar. Four of their demands are built in.
- Every answer traceable and reproducible. Citations and run records take you from an answer back to the sources, rules and definitions that produced it.
- Least privilege by construction. A role reads only what its grants allow, and the compiler applies those grants to every query in every language.
- Residency by region. Tables, sources and materialized views carry a region. Moving one across a border takes a grant of its own.
- Review before production. A change reaches production through a merge request, approved by someone other than the person who asked for it.
Why one compiler can speak every language
Languages are ways of expressing logic, and the logic of data is bounded: select, join, aggregate, traverse. Transports are bounded too: whatever the protocol, data leaves through a socket as rows, nested documents, graphs, columnar batches or streams. Encoding is bounded as well: fewer than ten are meaningful, from PostgreSQL's wire rows and JSON to protobuf, Arrow, CSV, XML and Bolt's PackStream. Programming languages have shared one compiler infrastructure for twenty years; Provisa does the same for data.
It also works because data must be expressed relationally before it enters, and that simplifies every tool that reads it. Relational algebra has six primitive operations: selection, projection, union, set difference, Cartesian product and rename; join and the rest are built from them. Even deep traversals can be recursive CTEs, and a property graph's nodes can be expressed as sparsely populated tables by label, and its edges as junction tables, sparse again. Think hard enough and every one of these languages can be expressed in an IR based on extended relational algebra: those six operations plus aggregation, recursion and nesting.
Building a compiler front end has also become cheap: parser generators like ANTLR and mature open-source parsers for SQL, GraphQL and SPARQL do most of the work, so adding a language means writing a translation into the IR instead of a new system. Each request is compiled when it arrives into one IR, governed there, handed to your engine as native SQL, and encoded on the way out for the transport that asked.
Where languages or protocols differ at the edges, their public conformance suites settle it. Provisa runs them and publishes the results.
So data languages become more about the UX and less about the logic. Conceptually that is a small overstatement: there are a few edge cases, but not a lot, and each language's conformance suite pins them down. Practically, tooling and skill sets really care, and that is why the tradeoff is worth accepting: every team keeps the language and tools it knows, and all of them read one model with one set of rules.
It also means the pace of change isn't a constraint. New query languages, protocols, engines and sources keep arriving; for most stacks each one is a migration. Here, a new language or transport is a front end or an encoder, and a new engine or source is a driver. Those are additions at the edges, and the model and its governance don't change. This compositional model of primitives makes it all plug and play.
Command bindings
If Provisa doesn't support a library or tool you already use, you can create its command bindings. A command is written once, and every language can call it, each under the name that language's callers expect. That's apoc.meta.data for a Cypher tool, a catalog function for a SQL client, a field in GraphQL, a tool in MCP.
Every command is offered in every language by default. Renaming it or leaving it out of a language is an explicit choice, and SQL is always there because everything compiles to it. Where a language expects a different result shape, that variant is its own command. Each one runs governed, so a mimicked tool call never sees more than the role may read.
That's how Provisa speaks APOC to Neo4j tools and agent frameworks, and it's how you teach it any other dialect yourself, without waiting for a release.
What you can check today
The generated SQL is visible for any query in the explorer: write a GraphQL query and the Query Language Explorer shows its Semantic SQL and Cypher translations live, beside your query, before it runs.
The live sandbox at sandbox.provisa.dev opens a private environment with data already loaded. Run a query, read the plan, and verify it yourself.
What Provisa is not
Is Provisa a database, or does it replace my warehouse?
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, and your semantics live in the model.
Why the engine should be replaceable.
How is this different from Starburst or Denodo?
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.