Databases

Qovery natively lets you deploy and access the most popular SQL and NoSQL databases available on the major cloud providers. Reliability and resiliency are at the heart of their services, so you don't have to worry about your data on Qovery.

Qovery natively supports the following databases:

  • PostgreSQL
  • MySQL
  • MongoDB
  • Redis

Qovery can natively operate a database in two different ways (called "Mode"):

  • Container mode: preferred for testing and development
  • Managed mode: preferred for production, limited configuration parameters (see the Configuration section).

If the natively supported databases or operation modes are not enough for you, depending on your use case you have the following alternative solutions:

  • Use an existing DB on a dedicated VPC: your applications can access this database via VPC peering. Have a look at this guide for more information.
  • Create your custom database via Qovery: You will be able to deploy any kind of database through Qovery by using a lifecycle jobs. For example, you can use a terraform script to deploy your custom RDS instance on AWS via Terraform (have a look at this example).

The following sections will show you how you can create and manage the databases natively supported by Qovery. For any other use case, please refer to the guides provided above.

Container mode

The database is created as a container with attached persistent storage directly on your Kubernetes cluster (1 instance). They are perfect for development and testing, as they are significantly cheaper than services provided by cloud providers.

Managed mode

Qovery creates and manages the lifecycle of a cloud provider managed database instance (for example an RDS instance on AWS). These are perfect for production since they guarantee the right level of resilience, performance and data security best practices.

Applying changes to a managed database

Once you request to change the version, instance type or disk size of your Managed database, the cloud provider applies the update based on its own internal rules and might cause downtime of your database.

For example, by default AWS doesn't apply major updates immediately on the database and instead, it waits for a maintenance window. This means that your change will not be applied immediately but you can always force the change directly from your AWS console AFTER having applied the change on Qovery (to avoid configuration drifts).

Have a look at your cloud provider documentation to know more about how version upgrades are managed:

Create a database

  1. Navigate to Console

  2. Select your project and environment

  3. Click Add Database button

    Database

  4. Select database type, name, description (optional), version, mode and accessibility

    General Information

    Extra labels/annotations (optional)

    Add your extra annotation/label groups. See the Add annotation/label group section for more information. Annotation groups are not supported for managed databases.

  5. Within the "Resources" step you will find different configurations based on the selected mode:

    • If you are using the database in Container mode, you can set the CPU, RAM and storage that will be assigned to the instance running the docker image of the database.
    • If you are using the database in Managed mode, you can select the instance type and the storage that will be assigned to the instance running the database. Note, the instance selected instance type has a direct impact on your cloud provider cost.

    Resources

  6. At the end a recap will allow you to just create the database or create and deploy it

    Recap

Configuration

Once created, you can access the configuration of a database at any time via the Settings tab available on the database page

Database Settings

You can find below the description of each of the tabs available in this section

General

Modes

As described at the beginning of this document, databases can operate in two modes:

  • Managed
  • Container

Managed databases are perfect for production - they are provided and managed by major cloud providers like AWS to make sure your production data is well managed.

Container databases are managed by Qovery as Docker containers with attached persistent storage directly on your Kubernetes cluster (1 instance). They are perfect for development and testing, as they are significantly cheaper than services provided by cloud providers.

Please refer to the dedicated database sub-pages to get more information on the supported mode for each cloud provider.

Versions

We regularly update the version available for each database. Please refer to the dedicated database sub-pages to get more information on the supported version for each database types and cloud provider.

You can upgrade the version of your database directly from the Qovery interface.

Accessibility

This parameter lets you decide whether to expose publicly or not your database.

  • Public access will make your database accessible via the public network
  • Private access will make your database accessible only by applications in your environment

Extra labels/annotations

Add your extra annotation/label groups. See the Add annotation/label group section for more information. Annotation groups are not supported for managed databases.

Resources

CPU / Memory

This configuration is available only for databases in Container mode

You can select the CPU assigned to the Kuerbetes pod running the database instance

Instance Type

This configuration is available only for databases in Managed mode

You can modify the CPU assigned to the instance running your database (And thus, its resources).

Storage

You can select the size of the persistent storage attached to the container database.

Credentials and connectivity

When a database is created in your environment, Qovery will automatically create and inject a set of BUILT_IN environment variables containing all the parameters necessary to your application to connect to the database.

This is the list of environment variables and secrets that will be automatically created:

NameDescriptionExample
QOVERY<DATABASE_TYPE><DBID>_DEFAULT_DATABASE_NAMEEnv Var containing the default database namepostgres
QOVERY<DATABASE_TYPE><DBID>_HOSTEnv Var containing the external hostname of the database (if you need access from the outside and the DB is configured with visibility "PUBLIC")zf5206c84-postgresql.oom.sh
QOVERY<DATABASE_TYPE><DBID>_HOST_INTERNALEnv Var containing the internal hostname of the database (if you need access it from within the cluster network)zf5206c84-postgresql
QOVERY<DATABASE_TYPE><DBID>_LOGINEnv Var containing the username of the DBsuperuser
QOVERY<DATABASE_TYPE><DBID>_PORTEnv Var containing the port to be used for connecting to the DB5432
QOVERY<DATABASE_TYPE><DBID>_DATABASE_URLSecret containing the external URI to be used for connecting to the DB (if you need access from the outside and the DB is configured with visibility "PUBLIC")sql://root:[email protected]:27017/admin
QOVERY<DATABASE_TYPE><DBID>_DATABASE_URL_INTERNALSecret containing the internal URI to be used for connecting to the DB (if you need access it from within the cluster network)sql://root:xxxx@z4a58c1e2-postgresql:27017/admin
QOVERY<DATABASE_TYPE><DBID>_PASSWORDSecret containing the password of the DBdbsecret

Please note that the built-in variables follow the naming pattern: QOVERY_DATABASETYPE + <your_db_name> + <type_of_variable> where:

  • <your_db_name> is the name of your database
  • <type_of_variable> is the type of variable we inject, e.g. PASSWORD, VERSION, CONNECTION_URI and so on.

To know how to access your database from your application, have a look at the database section.

Clone

You can create a clone of the service via the clone feature. A new service with the same configuration (see below for exceptions) will be created into the target environment.

Clone Service

The target environment can be the same as the current environment or even another one in a completely different project.

Important information

Not every configuration parameter will be copied within the new service for consistency reasons. The configuration is fully or partially copied depending on the target environment:

  • same environment:
    • custom domain: this setup is not copied into the new service (to avoid collision)
  • another environment:
    • custom domain: this setup is not copied into the new service (to avoid collision)
    • environment variable: aliases defined on environment variables are not copied (since the aliased env var might not exist)
    • deployment pipeline: stage setup is not copied (since the target stage might not exist)
    • number of instances: if the target environment runs on a Qovery EC2 cluster, the max number of instances is set to 1 (Qovery EC2 constraint)

Please check the configuration of the new service before deploying it.

Delete your database instance

  1. Navigate to Console

  2. Select your environment and database

  3. In database overview, click on Action remove button

    Database Remove

Available Databases

Mongodb
Mysql
Postgresql
Redis