-
Notifications
You must be signed in to change notification settings - Fork 393
Server Database
Note: This feature is available in Enterprise and AWS editions only.
By default, the H2 database is used as the internal database for the Community, Enterprise, and AWS Editions of CloudBeaver. The Team Edition employs PostgreSQL.
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. This migration is designed to seamlessly transfer all server data from H2 to PostgreSQL with minimal intervention required.
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.
For deployment details, refer to the repository: CloudBeaver deploy.
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.
-
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
- 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.
- 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.
- Application overview
- Demo Server
- Administration
- Server configuration
- Create Connection
- Connection Templates Management
- Access Management
-
Authentication methods
- Local Access Authentication
- Anonymous Access Configuration
- Reverse proxy header authentication
- LDAP
- Single Sign On
- SAML
- OpenID
- AWS OpenID
- AWS SAML
- AWS IAM
- AWS OpenId via Okta
- Snowflake SSO
- Okta OpenId
- Cognito OpenId
- JWT authentication
- Kerberos authentication
- NTLM
- Microsoft Entra ID authentication
- Google authentication
- User credentials storage
- Cloud Explorer
- Cloud storage
- Query Manager
- Drivers Management
- Supported databases
- Accessibility
- Keyboard shortcuts
- Features
- Server configuration
- CloudBeaver and Nginx
- Domain manager
- Configuring HTTPS for Jetty server
- Product configuration parameters
- Command line parameters
- Local Preferences
- API
-
CloudBeaver Community
-
CloudBeaver AWS
-
CloudBeaver Enterprise
-
Deployment options
-
Development