Data governance catalog

Onehouse ships with its own data governance catalog. It is compatible with the Iceberg REST Catalog (IRC) protocol, so any Iceberg client connects to it as a standard REST catalog, and it applies the same access policies to tables in every other format: Apache Hudi, Delta Lake, plain Parquet and ORC tables, and the Hive tables you already have. Every Onehouse engine in your project uses the catalog to enforce those policies on every query.

One catalog for every format

• Iceberg tables are served through the Iceberg REST API, so Spark, Trino, PyIceberg, and any other Iceberg client read and write them with standard catalog configuration.
• Non-Iceberg tables, including Hudi, Delta Lake, Parquet, ORC, and plain Hive tables, are registered in the same catalog through a path specific to each format. Engines resolve them by name, and the same privileges, down to row filters, govern them. You can bring existing Hive tables under governance without converting them.

SQL and Spark clusters can instead use one external catalog per cluster: the AWS Glue Iceberg REST endpoint, Snowflake Open Catalog, Microsoft OneLake, or any other Iceberg REST-compatible catalog, so teams that standardize on another catalog can keep using it as well. Clusters on an external catalog do not enforce Onehouse catalog policies.

The Onehouse governance catalog, another IRC catalog per cluster, and OneSync keeping tables and permissions in step across catalogs.

The catalog is the primary catalog for Onehouse SQL and Spark clusters, Lakegres, and notebooks, and it works alongside the external catalogs you already run: OneSync registers the same tables in AWS Glue, Databricks Unity Catalog, Snowflake, and Microsoft OneLake, and syncs table and database privileges to Lake Formation, Unity Catalog, Snowflake, and OneLake. Row filters and column masks are not synced.

Access policies

Policies follow the structure of your data. Tables are organized as lake, database, and table. Principals are users and groups from single sign-on and SCIM provisioning, and service principals created in Onehouse. To cover every table in a database, or every database in a lake, including ones created later, grant ON ALL TABLES IN DATABASE or ON ALL DATABASES IN LAKE. A grant on a single object applies to that object only.

Privilege	Grantable on	What it allows
SELECT	Table	Read table data
INSERT	Table	Insert and update data, and take savepoints
DELETE	Table	Delete data
DESCRIBE	Lake, database, table	View metadata only, without access to data
ALTER	Lake, database, table	Change table metadata and services
CREATE_DATABASE	Lake	Create databases in the lake
CREATE_TABLE	Database	Create tables
DROP	Lake, database, table	Drop the object
ALL	Lake, database, table	Every privilege on the object

Policies apply at five levels of granularity:

Level	What it controls	Status
Database	Access to every table in the database, including future ones	Production
Table	Read, write, and administrative access to a single table	Production
Row	Row filters per principal and table, so each user sees only the rows they are entitled to	Production
Column	Which columns a principal can read	Preview
Column masking	Masking of values, such as hashing or redacting sensitive fields for specific principals	Preview

Policy evaluation builds on Apache Ranger, the standard for access control in open data lakes, so policies follow semantics that security teams already know. Grants and revocations are made in the console, through the SQL command API (GRANT PRIVILEGE, REVOKE PRIVILEGE), or via UI panels.

Where policies are enforced

The same policies are enforced at every point a query can reach your data:

• The catalog server makes every access decision. Engines and Iceberg REST clients ask it before listing, opening, creating, altering, or dropping a table: listings are filtered to what the principal may see, loading a table it may not read is refused, and commits are checked against write privileges.
• Spark, SQL, and notebook clusters check table access through the catalog plugin for every format. A query-plan extension applies row filters and column access rules before the query runs, so the plan that executes is already filtered and masked. Lock storage access down to the engines, and have each cluster vend short-lived credentials for the data its policies allow.
• Lakegres enforces the same policies on every query its Postgres endpoint serves, including the tool calls agents make through the AI Gateway.

The control plane authenticates every request and passes the end user’s identity to each engine, so policies apply per user even on a shared SQL cluster or a notebook. Engines ask the catalog server for each decision. The catalog server evaluates it in memory against a policy set it refreshes every few seconds, an interval you can tune down to one second, so a grant or revoke takes effect within that window. On the TPC-DS suite at 1 TB and 10 TB, on Iceberg and Hudi, table-level authorization added no measurable query time; results were within normal run-to-run variation.

Further reading

• Announcing OneSync Permissions
• Security and governance
• Catalog interoperability