Skip to main content
You need to have created an Environment first.
Qovery lets you deploy two kinds of databases. Pick one based on what you need: If neither option fits your use case, you can also:
  • 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.
Looking for Managed mode? Databases created in Managed mode before Blueprints keep working. See Legacy managed databases.

​
Managed database (Blueprint)

A managed database is provisioned through a Blueprint. With a cloud provider blueprint (AWS, GCP, Scaleway), the database runs as a managed service in the cloud account backing your cluster. Backup and maintenance behavior depends on the provider and the Blueprint configuration. Helm blueprints run on the cluster itself, and External blueprints provision a third-party SaaS resource (for example MongoDB Atlas). The Databases & Caches category of the catalog includes, among others, Amazon RDS for PostgreSQL and MySQL, Amazon ElastiCache for Redis and Valkey, Google Cloud Memorystore for Redis, Scaleway Managed PostgreSQL, and Scaleway MySQL. See the Blueprints catalog for the full list and supported versions.

​
Create a managed database

1

Pick a database blueprint

In the Console, open the environment where you want the database and click the New service button. In the Databases & Caches category, select the blueprint you need (for example Amazon RDS for PostgreSQL). Cloud provider blueprints are filtered to the provider of the target cluster.
2

Choose a version

Select the major version (for example PostgreSQL 17).
3

Fill in the variables

Complete the form generated from the blueprint. Required variables are marked, optional ones fall back to their defaults. Read the blueprint README to know which inputs are required.
4

Create and deploy

Create the service, and deploy it immediately or later.

​
Connect your application

Once deployed, the blueprint service publishes its outputs (endpoint, port, credentials). Other services in the same environment consume them through variable interpolation. See Outputs. To change the database settings later, or to move to a newer blueprint version, see Editing a Blueprint Service and Updating a Blueprint.

​
Container database

The database runs as a container with attached persistent storage directly on your Kubernetes cluster (1 instance). Use it for development and testing only: container databases have no automated backups or snapshots. For production, use a managed database Blueprint. Supported databases are PostgreSQL, MySQL, MongoDB and Redis.

​
Create a container database

Check out this guide to create and deploy your first database.
1

Navigate to Console

Navigate to Console
2

Select your project and environment

Select your project and environment
3

Create a new service

Click the New service button, then select Database as the service type
4

Select database configuration

Select database type, name, description (optional), version and accessibility.
Please refer to the Configuration section below to know more about each of these parameters.
Extra labels/annotations (optional)Add your extra annotation/label groups. See the Add annotation/label group section for more information.
5

Set Resources

Within the “Resources” step you can set the CPU, RAM and storage that will be assigned to the instance running the docker image of the database.
6

Create and Deploy

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

​
Configuration

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

​
General

  • Version: we regularly update the versions available for each database. You can upgrade the version of your database directly from the Qovery interface.
  • Accessibility: decide whether to expose your database publicly or not. Public access makes your database accessible via the public network. Private access makes it 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.

​
Resources

  • CPU / Memory: the CPU and memory assigned to the Kubernetes pod running the database instance.
  • Storage: 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: 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 a database

Delete action drops the service and its data!
1

Navigate to Console

Navigate to Console
2

Select your environment and database

Select your environment and database
3

Delete Database

In database overview, click on Action remove button

​
Legacy managed databases

Managed mode is deprecated and can no longer be selected when creating a database from the Console. To create a new managed database, use a Blueprint.Existing managed databases keep working. They are configured, cloned and deleted the same way as container databases, with the differences below.

​
Migrate to a blueprint

Eligible AWS PostgreSQL managed databases can be migrated to a blueprint without re-provisioning or data movement. See Migrating a Managed Database to a Blueprint.

​
Differences with container databases

Existing managed databases expose the same built-in environment variables as container databases. Instead of CPU / Memory, their Resources tab lets you change the Instance Type of the instance running the database. Annotation groups are not supported for managed databases. As managed 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 them manually.

​
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: If you need to minimize downtime during an RDS upgrade, check out our tutorial: Minimize downtime while upgrading RDS instances.