Provisa / No lock-in
The platforms you're locked into become engines you can replace.
When a new strategy means changing platforms, you migrate the data and you also rebuild the queries, the governance model and the API contracts for the new system. Teams that have done this know the cost. The semantics live above the infrastructure here, so your vendors become components you can replace instead of foundations you rebuild on.
No lock-in to an engine or a source
Your model, semantics and governance live above the infrastructure, not inside it, so changes there don't reach the people using the data. 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, or MongoDB to Snowflake, and consumers never see it move.
That turns data modernization into an incremental effort instead of a big-bang cutover. Migrate sources table by table behind a stable governed API, with one uniform governance model applying to legacy and modern sources alike throughout the transition. That is the part that usually kills these programs: the interim state normally means two governance models and a spreadsheet reconciling them.
With your semantics above the engine, vendors have to compete for your workloads.
We don't lock you in either
Provisa is a handful of primitives (domains, tables, relationships, masking, views) compiled deterministically. There is no proprietary modeling universe to learn and no black box. Your model is portable declarative config, and the SQL it compiles is yours to read, export, and keep.
Use it as scaffolding in dev if that's all you want. The semantics you write don't die with the tool, because they were never trapped inside it. A vendor that argues you should be able to leave its dependencies has to be willing to let you leave it, too.
Split the physical layer, keep one logical model
Performance needs fragmentation: the right engine per workload, replicas at the right granularity. Consumers need one coherent model. Fragmenting the physical used to fragment the logical too: a pile of models with clashing objectives and granularity, and physical detail bleeding into logical design.
Provisa separates the two. Specialized engines and materialized views sit underneath, one governed logical model sits on top, and the physical never bleeds into the contract your consumers see. The settings that split work across engines for speed live in the same declarative model, so going faster never creates a second model.
Domains as products, delegated
Give a domain its own owner, with rights scoped to it: register sources, publish tables, wire relationships and ship views inside that domain, and none of it reaches another. Central policy still governs every query. Authorship is federated; enforcement is shared.
Promote config like code
Analysts and developers work in an environment of their own, a branch of the model: they register sources, publish tables and wire relationships there. Their changes merge back through a request that someone approves, and an environment can push to your own git repository. So changes go through the release process you already run, whether that is a manual review or a fully automated pipeline.
You set the compute bill
Because every query passes through one model, Provisa also decides where each one runs: how fast it is, how much data crosses the network, and which vendor's engine you pay for it.
Single-source queries route direct to the driver. Hot lookups inline as VALUES CTEs. Queries rewrite onto a fresh materialized view when one covers them. Each of those is a decision about whose meter is running, made in one place instead of in every team's query.