Skip to content

Server database

CloudBeaver supports the following internal databases:

  • PostgreSQL (default)
  • MariaDB
  • Oracle
  • SQL Server
  • H2

Info

Starting with version 24.2.0, PostgreSQL becomes the default database in the Docker Compose configurations we provide for the Enterprise and AWS Editions. The Community Edition continues to use the H2 database.

If you have previously used the H2 database and are transitioning to new Docker Compose setup, an automatic migration to PostgreSQL will be triggered.

Accessing the database

  1. Identify database connection parameters used by the server

    Tip

    Look for CLOUDBEAVER_DB_* in the .env file or backend.cloudbeaver_db_*in k8s/values.yaml.

  2. Create a connection

    Example

    Typical PostgreSQL connection settings.

    • Host: postgres
    • Port: default is 5432
    • Database: default is cloudbeaver
    • User: value of CLOUDBEAVER_DB_USER
    • Password: value of CLOUDBEAVER_DB_PASSWORD

    Default credentials depend on your deployment configuration and may differ from standard PostgreSQL defaults.

  3. Open the cloudbeaver database.

Changing the database password

  1. Change passwords value:

    • for compose .env value of CLOUDBEAVER_DB_PASSWORD variable
    • for k8s in k8s/values.yaml value of backend.cloudbeaver_db_password variable

    Example

    CLOUDBEAVER_DB_PASSWORD=NewStR0NgP2sSw0rD.

  2. Login into postgres container:

    • for compose from deployment dir run docker compose exec -it postgres psql -U postgres
    • for k8s with kubectl run kubectl exec -it postgres-*********-***** -- psql -U postgres

  3. Change postgres password:

    • ALTER USER postgres WITH PASSWORD 'NewStR0NgP2sSw0rD';

  4. Restart or redeploy cluster services:

    • for compose in deployment dir execute docker compose up -d command
    • for k8s in deployment dir execute helm upgrade cloudbeaver ./k8s

Automated migration from H2 to PostgreSQL

Warning

Update only the database login and password. Any other changes will break the migration.

To ensure the automated migration from H2 to PostgreSQL occurs, you need to use the version 24.2.0 or later. This migration is necessary for older installations. If it's a new deployment, migration is not required because there is no old data and PostgreSQL will be used immediately.

Info

For deployment details, refer to the CloudBeaver deploy repository.

Migration conditions

For the migration to be initiated, the following conditions must be met:

  • CloudBeaver must be set to use the standard H2 configuration.
    • ${workspace}/.data/cb.h2v2.dat should be a valid standard database.
    • ${workspace}/.data/my_db_name.h2v2.dat is a custom H2 database which will not trigger migration as it indicates manual customization by the administrator.
    • ${workspace}/.data111111/cb.h2v2.dat is also considered a custom database.

Environment configuration

Standard environment values for database connection must be in place:

  • Driver: CLOUDBEAVER_DB_DRIVER=postgres-jdbc
  • URL: CLOUDBEAVER_DB_URL=jdbc:postgresql://postgres:5432/cloudbeaver (changes to the host or database name prevent migration).
  • Schema: CLOUDBEAVER_DB_SCHEMA=cb (must not be changed).

The following Query Manager (QM) environment settings should match:

  • CLOUDBEAVER_QM_DB_DRIVER=${CLOUDBEAVER_DB_DRIVER}
  • CLOUDBEAVER_QM_DB_URL=${CLOUDBEAVER_DB_URL}
  • CLOUDBEAVER_QM_DB_SCHEMA=qm

However, it is advisable to change the PostgreSQL username and password for security reasons:

  • CLOUDBEAVER_DB_USER=postgres
  • CLOUDBEAVER_DB_PASSWORD=StR0NgP2s

During migration

  • The application will not be accessible, and an error message will be displayed across the screen to prevent any operations that might disrupt the process.
  • Migration includes the internal database with user lists and access rights and the Query Manager (QM) with the history of executed queries.
  • If the QM has a substantial amount of data, the migration might take an extended period, during which it is advised not to turn off the server.

Post-migration

  • Once migration is successful, the old databases are backed up and are not directly accessible; they will be stored with new names in their original locations.
  • Reverting to the old configuration is possible only through manual intervention.