> ## Documentation Index
> Fetch the complete documentation index at: https://www.qovery.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Databases
> Learn how to configure Databases on Qovery
You need to have created an [Environment](/configuration/environment) first.
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](#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](/configuration/integrations/aws/vpc-peering) 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](/configuration/lifecycle-job). For example, you can use a terraform script to deploy your custom RDS instance on AWS via Terraform (have a look at [this example](https://github.com/Qovery/lifecycle-job-examples/tree/main/examples/aws-rds-with-terraform)).
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](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](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_UpgradeDBInstance.Maintenance.html)
If you need to minimize downtime during an RDS upgrade, check out our tutorial: [Minimize downtime while upgrading RDS instances](/getting-started/guides/advanced-tutorials/upgrading-rds-instance).
## Create a database
Check out [this video guide](/getting-started/guides/getting-started/connect-database) to create and deploy your first database
Navigate to [Console](https://console.qovery.com)
Select your project and environment
Click `Add Database` button
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.
**Extra labels/annotations (optional)**
Add your extra annotation/label groups. See the [Add annotation/label group](/configuration/organization#labels-and-annotations) section for more information. Annotation groups are not supported for managed databases.
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.
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.
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](#applying-changes-to-a-managed-database) 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
#### Extra labels/annotations
Add your extra annotation/label groups. See the [Add annotation/label group](/configuration/organization#labels-and-annotations) 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 Kubernetes 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](#applying-changes-to-a-managed-database) 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](#applying-changes-to-a-managed-database) 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\_``\_``\_DEFAULT\_DATABASE\_NAME | Env Var containing the default database name | postgres |
| QOVERY\_``\_``\_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\_``\_``\_HOST\_INTERNAL | Env Var containing the internal hostname of the database (if you need access it from within the cluster network) | zf5206c84-postgresql |
| QOVERY\_``\_``\_LOGIN | Env Var containing the username of the DB | superuser |
| QOVERY\_``\_``\_PORT | Env Var containing the port to be used for connecting to the DB | 5432 |
| QOVERY\_``\_``\_DATABASE\_URL | 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:[xxxx@z4a58c1e2-postgresql.oom.sh](mailto:xxxx@z4a58c1e2-postgresql.oom.sh):27017/admin |
| QOVERY\_``\_``\_DATABASE\_URL\_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\_``\_``\_PASSWORD | Secret containing the password of the DB | dbsecret |
Please note that the built-in variables follow the naming pattern: `QOVERY_DATABASETYPE` + `` + `` where:
* `` is the name of your database
* `` 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](/configuration/environment-variables#connecting-to-a-database).
## 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.
Navigate to [Console](https://console.qovery.com)
Select your environment and database
In database overview, click on `Action` remove button
## Available Databases
NoSQL document database
Popular relational database
Advanced relational database
In-memory data store