Personal Databases¶

What is a Personal Database?¶

A Personal Database (PDB) is a system-owned, user-managed database instance that is automatically provisioned by Snowflake. It serves as a dedicated, personal storage location where users can create, organize, and manage their own database objects.

Automatic provisioning removes the administrative requirement for users to manually select or request access to a shared database, which ensures a dedicated development environment. When a user is dropped from the system, their associated PDB and all its objects are automatically transferred to ACCOUNTADMIN ownership.

Advantages of a PDB¶

Organize personal projects: Users can organize their own projects in an isolated environment, reducing clutter and potential naming conflicts in shared databases.
Easy administrator governance: All file-related developments are fully governed by RBAC.

PDB object types¶

PDBs support the following object types:

Application services
Artifact repositories
Git repositories
Schemas
Secrets
Workspaces

Workspaces¶

The PDB is created when a user first interacts with the Workspaces UI. Workspaces are file-based entities and require storage within a Snowflake database.

Security¶

The PDB’s architecture is intentionally streamlined and adheres to the principle of least privilege, which ensures that all operations are strictly limited to the user’s existing security context:

No new data access: PDBs do not introduce any new or expanded access to data or any additional ability to share data. Users can’t move data from a regular database to a PDB.
Permissions context: Any SQL queries executed within a workspace are run with the exact same set of roles and permissions that the user already possesses. This mirrors the execution environment of a standard Snowflake workspace file.

Note

Personal databases also support personal secrets. Secret objects are owned exclusively by the user. This ensures, by default, that the secret remains private, is accessible only to the user, and is not shared unintentionally.

Use feature policies with personal databases¶

Account administrators can use feature policies to control which object types users are allowed to create in their personal databases. This lets organizations enforce governance rules across all personal databases in the account.

A feature policy can block the creation of any object type supported in personal databases.

Note

Account-level object types such as WAREHOUSES, COMPUTE POOLS, and DATABASES have no effect when a feature policy is bound to personal databases. Those types only apply when a feature policy is bound to native apps.

Important

Feature policies only prevent the creation of new objects. Existing objects are not affected and will continue to exist. To enforce a policy on objects that already exist, remove them manually before or after applying the policy.

Applying a feature policy to personal databases¶

To create and apply a feature policy to all personal databases in the account, use the CREATE FEATURE POLICY and ALTER ACCOUNT commands:

CREATE DATABASE feature_policy_db;
CREATE SCHEMA sch;
CREATE FEATURE POLICY feature_policy_db.sch.block_app_services_policy
  BLOCKED_OBJECT_TYPES_FOR_CREATION = (APPLICATION_SERVICE);

ALTER ACCOUNT
  SET FEATURE POLICY feature_policy_db.sch.block_app_services_policy
  ON ALL PERSONAL DATABASES;

After applying this policy, users can no longer create application services in their personal databases.

To remove the policy from all personal databases:

ALTER ACCOUNT UNSET FEATURE POLICY ON ALL PERSONAL DATABASES;

Note

Binding a feature policy to a specific personal database is not supported. You can only apply a feature policy to personal databases using ON ALL PERSONAL DATABASES at the account level.

For more information about creating and managing feature policies, see Use feature policies to control object creation.

PDB management and visibility¶

Administrators can monitor and control usage of PDBs, which are owned by the system, not by any role. Usage on a PDB is limited to the user it is assigned to. Objects inside a PDB cannot be shared.

Administrator visibility¶

Roles with the MANAGE GRANTS privilege have visibility into all objects within the account, including personal objects owned by individual users. For example, roles like ACCOUNTADMIN can view all databases, including personal databases, by default. These roles can also access details about schemas and their objects within personal databases.

To view details for all personal databases within an account, query the DATABASES Account Usage view:
```
SELECT * FROM SNOWFLAKE.ACCOUNT_USAGE.DATABASES
WHERE DATABASE_NAME LIKE 'USER$%';
```
To view the workspaces that exist in a specific personal database, use the following code:
```
SHOW WORKSPACES IN DATABASE "USER$CMEYER";
```
To view a specific user’s personal database, use the following code:
```
SHOW DATABASES LIKE 'USER$BOBR';
```
For personal databases, the value in the kind column is PERSONAL DATABASE.
To view objects in a specific personal database, use the following code:
```
SHOW OBJECTS IN DATABASE "USER$<username>";
```

Drop a workspace¶

To drop a workspace in a personal database, use the following code:
```
DROP WORKSPACE "USER$JSMITH_DROP_WS_TEST".PUBLIC."drop_this_ws";
```

Cost considerations¶

Users cannot store data in tables in their PDBs.
Storage costs reflect only the size of the workspace files and associated metadata.

Limitations¶

Administrators cannot perform the following tasks:

View filenames or file contents that belong to other users.
View how much storage is used for PDBs. PDBs do not appear in DATABASE_STORAGE_USAGE_HISTORY.
Limit how much storage is used for each PDB.
Drop PDBs, or prevent individual users from using them.
Create new PDBs. New PDBs are created on demand when a user creates a workspace.