How to prevent users from creating Lakebase compute?

[charl-p-botha]

Dear community,

According to [1] and other sources, all workspace users are assigned `CAN_CREATE` on lakebase projects, and this permission "can't be revoked".

The problem is that such a project comes with by default a 8 - 16 CU lakebase compute instance (Scale-to-zero is enabled, but with a 24-hour idle timeout, any connection or query immediately resumes it, and it has a non-zero minimum (always-on baseline)), which means that anyone of our workspace(s) users is able to rack up a sizeable bill by accident. (the moment you create the project, the compute starts running).

After an in-depth exploration of all documentation and also the latest databricks cli, I have not been able to find any way to disable this regrettable default.

Please suggest a way whereby workspace users can be prevented from creating lakebase projects? We DO want to use lakebase for a number of our products, but we definitely also need to be able to specify who is able to create / use and who is not. (fully disabling the feature via support ticket as suggested in this forum post [2] would not work)

It would be far preferable to have it as an entitlement, or even connected to an existing entitlement (the aptly titled "Allow unrestricted cluster creation" could work), or first prize would be a revokable / assignable privilege. As it stands, there are no usable levers, which is highly uncharacteristic of Databricks products.

Please help.

Kind regards,
Charl Botha, Stone Three

[1] https://learn.microsoft.com/en-us/azure/databricks/oltp/projects/grant-permissions-programmatically
[2] https://community.databricks.com/t5/lakebase-discussions/disable-lakebase-and-model-serving-foundati...

[Ashwin_DSA]

Hi @charl-p-botha,

Based on the current public documentation, I believe your reading is correct. In a Lakebase-enabled workspace, CAN_CREATE is inherited by all workspace users and cannot currently be granted or revoked on a per-project basis. The Azure Databricks docs for granting permissions programmatically state that the grantable permission levels for Lakebase projects are only CAN_USE and CAN_MANAGE, and that CAN_CREATE is inherited automatically from the workspace and cannot be explicitly granted or revoked.

The same position is reflected in the public docs for managing project permissions, which say that the default permissions for a newly created project include CAN_CREATE for all workspace users. The public ACL reference also says that all workspace users automatically inherit CAN_CREATE and that this permission cannot be assigned or removed.

I agree that this feels out of step with the rest of the platform. A workspace-level entitlement, or a privilege analogous to existing compute-creation controls, would be a much more natural fit here. At the moment, however, I have not found any documentation describing a supported way to selectively prevent some workspace users from creating Lakebase projects while still leaving Lakebase enabled for others.

So my understanding is that the only clearly documented hard control is to disable the feature entirely at the workspace or account level through Databricks Support, which, of course, does not help if you want Lakebase enabled only for a controlled subset of users.

If you want to push for this, I think this is a reasonable product feature request to raise with Databricks. You can submit it through the Databricks Ideas Portal, or from within a workspace using Send feedback. I would frame it specifically as a request for a workspace-level entitlement or revocable privilege that lets admins control who can create Lakebase projects, because that would directly address the governance and cost-management gap described above.

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.

[charl-p-botha]

Thank you very much for also looking into this.

I've submitted this as feedback via the new Lakebase Postgres web-ui. It doesn't look like I can link to that submitted feedback here. Let's hope for the best.