Provisa / Data mesh
Data mesh was a governance model, in its most complete sense. Provisa is its runtime.
Data mesh named the right ideas: domain ownership, data as a product, a self-serve platform, federated computational governance. It deliberately named no engine and no technology. What it never had was a runtime that enforces that governance on every query, over the systems each domain already runs. Provisa is that runtime.
Why mesh programs stall
Most mesh programs don't fail on the idea. They fail on the implementation, which usually means adopting a platform that owns processing.
- The rebuild. Every data product is re-implemented as a pipeline in the platform's runtime before it delivers anything. Teams spend quarters migrating instead of sharing.
- Centralized compute. A mesh needs central services: one model, one identity and policy, one catalog, enforced the same way for every domain. What it doesn't need is one platform running every job. When compute is centralized too, that platform becomes the bottleneck the mesh was meant to remove. Provisa centralizes the services and leaves processing on the engines and systems each domain already runs.
- Governance on copies. Rules apply to the copies the platform produces, not to the systems of record. Every product is another pipeline to keep fresh and another copy to secure.
Governance is five questions
Access control is one part of governance. The whole of it answers five questions about every piece of processing: where it runs, when it runs, how it is asked for, who it runs for, and what the data means. In Provisa each answer is declared once, in the model, and applied to every query.
Where to process
The model names the engine: embedded, Trino, Snowflake, Databricks, Postgres, ClickHouse and more, swappable by config. Single-source queries go straight to the source's own driver. Regions declare where data may be processed and stored, so residency is decided per query by the same model, not by a separate deployment per country.
This is where central services and central compute part ways. Under data residency laws such as GDPR, what matters is where personal data is processed and stored. The model, the policies and the catalog can be shared across every region; the personal data is processed by its own region's engine and stays in its own region's store. One definition of every region coordinates the cross-border rules, without moving the data to a central platform to apply them.
When to process
Freshness is declared per table: read live, replicate on a schedule, or follow changes. Materialized views record the transform that built them, and queries rewrite onto them while they're fresh. A load management window keeps heavy work off a source during its busy hours. Triggers run a command when data changes, when a load fails, or when a row is quarantined.
How to process
Consumers ask in the language and over the transport that suits them: SQL, GraphQL or Cypher, over pgwire, Bolt, Arrow Flight, gRPC, JDBC, REST, WebSocket, Airport or MCP. Every one of them compiles to the same governed plan, so a BI tool, an application, a graph browser and an agent get the same answer under the same rules. Writes are governed the same way and routed straight to the source.
Who to process for
Roles inherit from one another and combine through composite grants. Row-level security, column masking and pre-execution approval are compiled into the plan, and the rights that apply are always those of the acting role. An agent connecting over MCP carries an OAuth token that maps to a role, so it sees exactly what that role sees.
The meaning of what you process
Each domain owns a namespace, a glossary and its metrics, so sales and finance can each define "active customer" and consumers see which definition they are using. Relationships are registered, and joins are legal only along them, so a query can't invent a meaning the domains never agreed.
Metrics matter here, and the semantic layer has lately come to mean little more than a metrics layer. Provisa defines metrics once, in the same model as everything else, and also speaks Apache Ossie, the open standard for describing what metrics mean: import Ossie models from dbt, Cube, Snowflake or Databricks, and export the model as Ossie for the tools that read it.
The four principles, delivered in place
| Mesh principle | In Provisa |
|---|---|
| Domain ownership | Domains carve the model into namespaces. Each domain team registers its own sources, tables and relationships, with scoped rights that reach no other domain. |
| Data as a product | Data products follow the Open Data Product Standard (ODPS) as a thin layer over the model: each names the subset of a domain's tables, views, relationships and ontology that make up the product, with its owner, purpose and terms of use, and the quality measurements taken on it. Every product is addressable, discoverable, and queryable in SQL, GraphQL or Cypher over nine protocols, including MCP for agents. |
| Self-serve platform | One install or a hosted trial. 72 connectors reach 85+ kinds of source, and the file crawler catalogs shared drives and buckets nobody has mapped. |
| Federated computational governance | Where, when, how, who for and what it means, declared in config held in git and compiled into every query plan. Authorship is federated; enforcement is shared. |
A runtime you adopt, or a model over what you run
| Data-product runtime platforms | Provisa | |
|---|---|---|
| What a data product is | A pipeline packaged and run by the platform | An ODPS data product naming a subset of the model over existing sources |
| Getting started | Rebuild each product in the platform's runtime | Register the sources you have; query in minutes |
| Who runs processing | The platform's own engine | Your engine, chosen and swapped by config |
| Data movement | Products are materialized copies | Queries run in place; materialized views only where they pay off |
| Governance applies to | The copies the platform produces | Every query, compiled into the plan |
| AI agents | A separate access path to build | The MCP server, under the same roles and rules |
| Leaving | Products are tied to the runtime | Portable declarative config; the compiled SQL is yours to keep |
Start with one domain
You don't need an organization-wide program to begin. Start with the domain that has the most pain.
- Register the domain's sources. Point Provisa at the databases, SaaS systems and files that domain already owns.
- Import what's already defined. Bring tables, keys, relationships and metrics from dbt, Cube, Snowflake or Databricks through Apache Ossie. Each import is a proposal you review before it registers.
- Declare the products and the rules. Relationships, roles, row-level security, masking and freshness, once, in the domain's config.
- Publish. Consumers query over psql, Tableau, GraphQL, Arrow Flight or MCP, and one registration publishes to the catalog you already run.
- Add the next domain. Cross-domain joins follow registered relationships, so the mesh grows without a central pipeline team.
Frequently asked
Isn't this data virtualization with mesh branding?
Virtualization gives you one central layer that a central team maintains. Provisa gives each domain its own namespace, contracts and policies, with governance compiled per query. Ownership stays with the domain; only the enforcement is shared.
We've already started a mesh program. Do we start over?
No. Import the definitions you have from dbt, Cube or your warehouse's semantic layer, and keep your catalog: Provisa publishes into it with lineage.
Will a data product give the same answer every time?
It can, if it's designed carefully, or not. Reproducibility isn't the goal in itself; having the tools to create it where you need it is. Data changes constantly: sources update, late records arrive, and upstream fixes rewrite history. So each product carries the quality measurements taken on it, and where you need the same answer twice, for a period close, an audit or a training set, the tools are there: point-in-time and interval reads over the history Provisa records.
What about load on live systems?
That is a "when" question, and it's declared like the others: replicate a busy source on a schedule, hold heavy work to its load window, or materialize a heavily-used product and let queries rewrite onto it while it's fresh.