Can change a delta table, but not its schema
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-23-2026 01:43 PM
Is it possible to let a group in databricks to change a delta table, but not the table’s schema in UC? i.e., they can add or remove rows of the delta table, but cannot change the name or the format of the columns.
- Labels:
-
Unity Catalog
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-23-2026 02:23 PM
Hi @NW1000,
No, Unity Catalog doesn’t let you separate change rows from change schema that finely.
To let a group insert/update/delete rows on a table, you must give them MODIFY on that table. MODIFY also allows ALTER TABLE operations like ADD/DROP/ALTER COLUMN, so they can change the schema. They still can’t rename the table or change ownership without MANAGE or being the owner.
If you truly need row-only changes with a fixed schema, the usual pattern is... keep MODIFY on the base table for a service principal or pipeline only, expose data to users via views (SELECT only), and route all writes through controlled jobs.
If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.
Ashwin | Delivery Solution Architect @ Databricks
Helping you build and scale the Data Intelligence Platform.
***Opinions are my own***
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-22-2026 03:59 AM
Granting only MODIFY on the table allows the group to insert, update, and delete rows. MODIFY grants the ability to change the contents of a table without altering its schema or metadata - it does not include schema-altering privileges like ALTER or DROP. In short: MODIFY = control over rows, not structure.
--SQL GRANT MODIFY ON TABLE catalog.schema.your_table TO `your-group-name`;
The only thing to check is whether the group already inherits ALTER from a higher level, since privileges granted on a parent object are inherited by all current and future child objects. If they do, you will need to revisit those higher-level grants.