Multi-engine estates and ungoverned stores
Snowflake tells a mixed estate to run two policy domains. You don't have to.
No native catalog can express one access policy across Snowflake, Databricks, BigQuery, Redshift and PostgreSQL. Trinitis can, and it enforces it inside each engine's own controls.
Free for 2 databases. No card. Start in non-production.
“A GRANT in UC has no effect in Snowflake and vice versa. Each platform maintains an independent privilege model. There is no native sync.”
Source — Snowflake Engineering, 21 May 2026
Checked against the vendors' own documentation
What each native catalog governs.
Snowflake's recommendation for an estate on both platforms is two catalogs, two privilege models. Anything outside both is governed by its own grants, by hand.
Sources — Snowflake catalog-linked databases · Databricks Lakehouse Federation · Databricks external access
- Governed by that platform's native catalog
- Outside governance
What we don't claim
If you run one engine, use its native controls.
A single-platform estate is well served by Horizon or Unity Catalog, and we will say so on the call. Snowflake's Iceberg Scan Plan API (public preview, 10 September 2026) enforces row and column policy for any Iceberg REST engine, so cross-engine enforcement for Iceberg tables is real. It does nothing for Redshift, for Postgres, or for anything that is not an Iceberg table.
Source — Snowflake release notes, 10 Sep 2026
The product
One policy, written into every engine.
- The same dataset, governed three ways across three engines, in one view.
- One policy approved for it. Trinitis writes it into each engine's own controls.
Illustration
Stop maintaining access in three places.
Free for 2 databases. No card. Start in non-production.