Database Options

All Bitwarden self-hosted server deployments, except for unified, ship with an MSSQL Express image by default. This colocates your encrypted vault data with the application containers and simplifies deployments by ensuring that updates, maintenance, and backups are delivered concurrently with the rest of the code.

This default database does not require additional licensing and is pre-configured to Bitwarden standards to securely store and automatically backup vault data (learn more).

In those self-hosted server deployments that are shipped with an MSSQL Express image, use of that container is optional. For high-availability or to leverage existing infrastructure, customers may connect to an external MSSQL server or cluster (learn more) of version 2019 or higher. Version 2022 or higher is, however, recommended.

Bitwarden unified self-host deployments do not ship with a built-in database, but can connect to an existing MySQL/MariaDB, MSSQL, SQLite, or PosgreSQL database (learn more). As this database is not collocated with the application container, database maintenance from an infrastructural perspective, including updates, maintenance, and backups, must be managed separately.

In non-unified self-host deployments, Bitwarden will check for the existence of the database specified in the constructed connection string and, if it doesn't exist, create it. This job requires the configured SQL user to have administrative privileges within the database server. Insufficient privileges will cause this job to fail.

If you are deploying your own external database, deactivate this deployment step by setting the following environment variable in global.override.env:

Bash
globalSettings__sqlServer__skipDatabasePreparation=true

In all self-hosted deployments, including unified, Bitwarden runs scheduled jobs on the database to perform routine maintenance, such as computing database statistics and building indices. These jobs require the configured SQL user to have administrative privileges within the database server. Insufficient privileges will cause this job to fail, which will be logged to admin container logs.

If you prefer to run these maintenance jobs as a separate user, deactivate this behavior by setting the following environment variable in global.override.env:

Bash
globalSettings__sqlServer__disableDatabaseMaintenanceJobs=true