Provisa / Compare / Provisa and data catalogs
Catalogs help you see the mess. Provisa stops it forming.
Data catalogs describe and govern data after it exists, alongside your systems, and that helps you see the mess. In Provisa the declaration is the system itself, so the mess never forms. Provisa then publishes to your catalog, which shows what is actually governed instead of what someone last wrote down.
Three different positions
See it
This is where catalogs are strongest. You can browse, search, tag, classify and document assets across every system, and Atlan, Collibra, Alation and DataHub all do this well. A steward can find any table, read its lineage and understand its business meaning. The catch is that the catalog came after the data. It describes what was built, and keeping that description accurate takes discipline.
Fix it
Catalogs can flag problems and let stewards annotate them. Some can propagate classification tags into the SQL warehouses they connect to. Fixing the underlying policy, the missing join, or the inconsistent name still means going back to the data platform itself. The catalog is beside the system; it cannot change it.
Stop it
This is where Provisa sits. You declare sources, tables, relationships and governance in a model. Provisa compiles that declaration into the running system. A table that is not in the model does not exist in any API, query result or published catalog entry. Drift cannot form because there is no gap between the declaration and what runs.
Where each fits
| You need to… | Catalogs | Provisa |
|---|---|---|
| Find and understand data across all your systems | ✓ Browse, search, filter and tag assets; descriptions and owners | ✓ Every governed table and column has a description, steward, domain, and business name in the model |
| Maintain a business glossary | ✓ Terms, definitions, synonyms, owners, and links to assets | ✓ Typed ontology: class, property and concept terms grounded directly to the tables and columns they mean |
| Track column-level lineage | ✓ Most scan lineage from query logs or pipeline metadata | ✓ Column-level lineage derived from model definitions instead of inferred from scans, and published with transforms |
| Enforce access policy on every source: warehouses, APIs, NoSQL, graph, code | Some push policy into the platforms they support: Collibra Protect writes masking and row filters into Snowflake, Databricks, BigQuery and AWS Lake Formation; Atlan syncs tags back to Snowflake and Databricks. APIs, NoSQL, graph and code sources fall outside that reach | ✓ Masking, row-level security and column visibility enforced identically on every protocol and source type: SQL, GraphQL, Cypher, SPARQL, MCP and more |
| Keep catalog descriptions in sync with reality | Periodic crawl or manual update; catalog and system drift apart between refreshes | ✓ Model is the source of truth; every change triggers a publish within seconds |
| Stop new data from existing outside governance | Describe existing assets; cannot prevent new ones from being created outside the catalog | ✓ A source, table or field that is not declared in the model is not exposed on any interface |
Use them together
Provisa publishes to your catalog automatically. Every governed table, column, domain, approved relationship, ontology term and column-level lineage edge flows to the target on each model change, typically within fifteen seconds. Your catalog does not need to crawl anything; it receives what Provisa knows.
Supported targets: OpenMetadata, DataHub, Collibra, Atlan (beta), Apache Atlas, Microsoft Purview, OpenLineage (Marquez and any OpenLineage consumer), Databricks Unity Catalog, Amazon DataZone, Google Dataplex, and Snowflake Horizon Catalog (data products). Configure one or several in Admin. Each gets the same snapshot, covering every domain you assign to it.
Governance signals travel with the publish. A masked column arrives in the catalog with the fact that it is masked and which roles the mask applies to. Rule bodies never leave Provisa, so the catalog does not expose your policy logic.
You can also take descriptions back. When a steward edits a table's description in the catalog, the Catalogs panel in Provisa lets them pull that edit into the model, table by table. Provisa never reads grants, row rules or masks from a catalog, because those belong in the model.
If you only need a catalog
You want to document and classify data that already exists across many teams and systems. Governance is handled by each platform independently. The problem you are solving is visibility and discoverability, not uniformity of enforcement. A catalog covers that on its own.
If you only need Provisa
You are building new APIs, governed access across source types, or a data control plane for a product. You want governance to hold from the moment data is declared, with nothing applied retroactively. You may not have an external catalog yet, or you want to keep the one you have accurate without manual effort.