Skip to main content
This guide explains how to wipe all user data from a Databunker Pro instance while keeping its configuration (tenants, roles, policies, encryption keys, license) intact. It is intended for resetting a test, staging, or to-be-decommissioned instance.
This operation is destructive and irreversible. It deletes every user across all tenants — the SQL TRUNCATE command ignores row-level security, so it cannot be limited to a single tenant. Never run it against a production database. Take a backup first.

​
Background

A user in Databunker Pro is identified by a UUID token. Beyond the main users table, the same token (or, for a few tables, the usertoken / record column) links a user to several auxiliary tables. A full cleanup must clear all of them: The tokenization vault (tokens) is not keyed by user token and is left out by default — see Tokenization vault below. Clearing files removes the metadata and the encryption keys, but not the stored objects themselves — see Stored file objects below.

​
Before you start

  • Direct (psql) access to the PostgreSQL database backing Databunker Pro.
  • A recent backup.

​
Truncate all user tables

Run the following statements. RESTART IDENTITY resets the auto-increment sequences (only usergroups actually uses one) so a fresh instance starts clean.
TRUNCATE empties the tables in a single fast operation and reclaims disk space immediately, so a follow-up VACUUM is not required.
Do not TRUNCATE the xtokens table. It holds the root and role access tokens (rows where usertoken is NULL) alongside the per-user login tokens. Wiping it would invalidate the root token and lock you out of the API. Delete only the rows that belong to a user with DELETE FROM xtokens WHERE usertoken IS NOT NULL AND usertoken::text <> '';, as shown above — this preserves the root and role tokens.
TRUNCATE ignores row-level security, so it always clears every tenant regardless of the my.tenantid session setting. If you need to remove the users of a single tenant only, delete by tenantid with DELETE statements instead of truncating.

​
Tokenization vault

If you use tokenization, a user’s sensitive fields may be stored in the tokens vault. This table is not keyed by the user token, so it is intentionally excluded above to avoid breaking tokens that are still referenced elsewhere. Truncate it only if you want to erase the entire vault as part of a full reset:

​
Stored file objects

The files table holds the metadata and the per-file key; the encrypted file itself lives in the configured object storage backend — local disk, Amazon S3, Google Cloud Storage, or Azure Blob Storage — under tenant/<tenantid>/<usertoken>/<fileuuid>. Truncating files destroys the keys, so the stored objects can never be decrypted again. What remains is unreadable ciphertext, plus object paths that still reveal which user tokens existed. Remove them as well to reclaim the space:
Do this after truncating the tables — deleting the objects first leaves metadata rows pointing at files that no longer exist.

​
What is preserved

The following configuration tables are not touched, so the instance stays usable after the cleanup: tenants, config (including the license key), encryptionkeys, policies, roles, rolepolicies, groups, connectors, legalbasis, and processingactivities.