Provisa / vs Starburst
Provisa and Starburst solve different halves.
Starburst is a Trino-based query engine and lakehouse platform. Provisa is a governed semantic layer that sits above an engine — including Starburst. The real comparison is not head-to-head; it's which layer you're missing.
Where they overlap
Both federate queries across heterogeneous sources without moving the data, and both make a strong argument against copying everything into one warehouse first. If your problem is "SQL analytics over many systems at scale," Starburst solves it well, and Provisa is happy to use it as the execution engine.
Where they differ
| Starburst | Provisa | |
|---|---|---|
| What it is | A query engine and lakehouse platform | A semantic and governance layer over an engine you choose |
| Query languages | SQL | SQL, GraphQL, and Cypher over one schema |
| Ways in | JDBC/ODBC, REST, client drivers | pgwire, Bolt, Arrow Flight, gRPC, JDBC, REST, WebSocket, Airport, MCP |
| Writes | Analytical, engine-mediated | Transactional writes routed direct to the driver, sub-100ms |
| The engine | Is the product | Is a swappable component — Trino, Starburst, DuckDB, ClickHouse, Postgres, Snowflake, Databricks, BigQuery |
| Smallest deployment | Cloud service or a cluster | pip install "provisa[embedded]" — no Docker, no JVM, no root |
Use both
If you already run Starburst, Provisa registers it as the federation engine and adds what an engine does not provide: per-role GraphQL schemas, Cypher over the same model, governed relationships that constrain which joins are legal, six layers of query-time governance on every transport, and an MCP server that gives AI agents the same governed access as a human — with no bypass.
The engine keeps doing what it is good at. What changes is that your semantics and policy stop living inside it, which is what makes the engine replaceable later.
Choose Provisa alone when
- You need GraphQL or Cypher, not only SQL.
- You have transactional and application traffic, not just analytics.
- Governance must hold identically across every API and protocol, agents included.
- You need to run in an airgap from a wheel, or on a laptop, without a cluster.
- You want the freedom to change engines later without rewriting queries or policy.
Choose Starburst alone when
- Your workload is large-scale SQL analytics and nothing else.
- You want a managed lakehouse with its own storage architecture and support contract.
- Your governance needs are met by engine-level access control.