Databases

Before you begin, this documentation assumes the following:

You have created an Environment.

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

Since Qovery manages the lifecycle of your database, DO NOT change the database settings directly from within the cloud provider console (to avoid configuration drifts).

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:

• AWS RDS DB engine upgrade: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.MySQL.html
• AWS maintenance window: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html

Create a database

Check out this video guide to create and deploy your first database

1. Navigate to Console

2. Select your project and environment

3. Click Add Database button

   

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

   Please refer to the Configuration section below to know more about each of these parameters.

   

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.

   

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

   

How was it? Did this tutorial work?  Yes  No

Configuration

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

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.

Any change on this field will not be applied immediately to your database, check the managed mode section.

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

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).

Any change on this field will not be applied immediately to your database, check the managed mode section.

Storage

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

Any change on this field will not be applied immediately to your database, check the managed mode section.

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:

Name	Description	Example
QOVERY<DATABASE_TYPE><DBID>_DEFAULT_DATABASE_NAME	Env Var containing the default database name	postgres
QOVERY<DATABASE_TYPE><DBID>_HOST	Env 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_INTERNAL	Env Var containing the internal hostname of the database (if you need access it from within the cluster network)	zf5206c84-postgresql
QOVERY<DATABASE_TYPE><DBID>_LOGIN	Env Var containing the username of the DB	superuser
QOVERY<DATABASE_TYPE><DBID>_PORT	Env Var containing the port to be used for connecting to the DB	5432
QOVERY<DATABASE_TYPE><DBID>_HOST	Secret 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>_HOST_INTERNAL	Secret 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>_PASSWORD	Secret containing the password of the DB	dbsecret

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.

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.

Note that only the instance configuration will be copied, not the data contained within the database.

Delete your database instance

Delete action drops the service and its data!

As Managed Services databases (like RDS) are mainly used for production, Qovery does not delete automated snapshots and backups on deletion. It is up to the user or Cloud provider Administrator to delete it manually.

1. Navigate to Console

2. Select your environment and database

3. In database overview, click on Action remove button

   

Available Databases

Mongodb

Mysql

Postgresql

Redis

How was it? Did this tutorial work?  Yes  No