Storage Analysis

The Storage analysis feature provides a global view of how the PostgreSQL database used by a workspace consumes storage, and exposes a small set of maintenance operations.

Access

Storage analysis is available only to users with the built-in organization admin role. That role has access to all projects in the workspace, which is required because some operations list record names from across the entire workspace database.

The Storage analysis screen is available at /workspace/:id/storage-analysis and can be reached from:

• The workspace dashboard Storage usage widget via the Storage analysis link (visible to organization admins only)
• The workspace quick access menu entry Storage analysis (visible to organization admins only)

How it works

Operations are grouped into sections on the page. Each section shows:

• A short description (read-only analysis vs write/maintenance)
• A Run button that starts the operation
• A Cancel button while an operation is in progress
• The last result as JSON

Potentially heavy operations (database bloat analysis and VACUUM FULL) show a confirmation dialog before they start, warning about possible performance impact.

Permissions

The permissions below refer to your Cloudomation user identity (or API token / webhook identity) and the roles assigned to it in Manage Users & Roles. They determine whether you can open the page and run operations.

• All operations require the built-in organization admin role. Users without this role cannot access storage analysis in the UI, and the backend rejects their requests.

note

The organization admin role is the built-in role with unrestricted access to all projects. It is assigned to at least the bootstrap user when a workspace is created. See Role Based Access Control for details on roles and permissions.

Operations

Read-only

Executions with many execution_dumps

Find executions that have a high number of execution dumps.

• Many dumps are created by executions that run many operations and/or run for a long time with savepoint_retention = ALL.
• Having many dumps is not necessarily a problem, but they may be unnecessary.
• Consider adjusting savepoint_retention for individual executions or globally.

Parameters: min_count, limit.

Executions with large execution_dumps

List the executions with the largest total execution dump storage.

• Dump size depends on the amount of data held in variables at dump time.
• To reduce storage usage, consider clearing large variables or adjusting savepoint_retention.

Parameters: limit.

Largest files

List the largest files stored in the workspace.

Parameters: limit.

Largest DB tables

Show the largest database tables by total on-disk size.

Parameters: limit.

Number of records per record_type

Count the number of records per record type.

Parameters: include_deleted.

Trash / deleted analysis

Show how many records exist, how many are in the trash, and how many are soft-deleted identity placeholder rows.

Soft-deleted identity rows cannot be linked because the original record no longer exists.

Total size per record_type

Estimate total size occupied per record type.

Parameters: include_deleted.

Database bloat

Estimate bloat per table (heap, indexes, and TOAST).

• Bloat is unused/wasted on-disk space that can accumulate after updates/deletes.
• VACUUM FULL can reclaim space, but it locks and rewrites tables.

Parameters: limit.

Write / maintenance

VACUUM FULL on selected tables

Run VACUUM (FULL, ANALYZE) on specific tables.

• This locks and rewrites the selected tables.
• Ensure you have enough free disk space for the rewrite.

Parameters: tables.

VACUUM FULL on all tables

Run VACUUM (FULL, ANALYZE) on all eligible tables.

• Heavy maintenance operation; expect a noticeable performance impact.
• Ensure sufficient free disk space for table rewrites.