Cloud Databases - FAQ

Cloud Databases, also known as Managed Databases, is a managed service allowing you to deploy and use database instances easily.

We provide cost-efficient services and take care of the infrastructure. We provide by design various features such as automatic backups, software updates, public or private networks, observability tools such as logs and metrics, and end-to-end security mechanisms.

Our Cloud Databases can be reached via Public network (Internet) or Private network (vRack), allowing you multiple use cases - connect with OVHcloud Public Cloud instances or Kubernetes clusters, OVHcloud Bare Metal, Hosted Private Cloud, OVHcloud VPS, etc. - but also allowing for Hybrid Cloud as long as you can use public network (Internet).

We are adding more and more Databases Management Systems over time. Please find the list and proposed versions in our Cloud Databases - Capabilities and Limitations guide.

Yes. Cloud Databases can be connected to a public network (Internet) or private network (vRack).

You can then connect them to any product compliant with these network topologies:

• Public network: any OVHcloud Cloud product.
• Private network (vRack): Bare Metal Cloud, Hosted Private Cloud, Public Cloud Instances, Public Cloud managed Kubernetes clusters.

Yes. You can reach your Cloud Databases services with a public network (Internet). You can then connect a third-party service, for example, another Cloud provider or on-premises infrastructure.

We expose our roadmap publicly on GitHub. You can filter by a label such as "Databases".

We built service plans based on business use cases. They have major differentiators, related to each DBMS.

Overall, we designed three service plans with these usages in mind:

• Essential: A perfect fit for testing, proof-of-concept, and development. Not for production purposes, mainly due to the lack of SLA, High Resiliency via clustering, or Private Network.
• Business: First level for development or production infrastructure. High resiliency is provided, with SLA.
• Enterprise: The highest level of services, with all the features and better SLA.

OVHcloud manages various tasks on your behalf:

• Setup: We are providing you with a database instance, with state-of-the-art installation, meaning that we take care of the provisioning, initial setup of the Operating System, and DBMS software.
• Once your database is running: Based on your service plan, we perform administrative tasks such as daily backups, updating the software, and providing security tools for authentication.

Still, since we provide database access, as a customer you are responsible for managing the services:

• Configuring the settings based on your use cases, including network, security, and backups.
• Defining your relational or NoSQL data schemas that will fit your needs.
• Performance tuning

OVHcloud Public Cloud allows you to create projects, then you will have quotas and billing per project. Quotas are visible in your OVHcloud Control Panel, they depend on your history. The default quota is limited to 20 instances per project.

Cloud Databases require a Public Cloud project. Once a project is created, you can start database instances via the OVHcloud Control Panel in just a few minutes.

Please read our Getting Started with Cloud Databases guide.

We use official and un-modified (vanilla) versions of DBMS, allowing you to rely on official documentation for each DBMS to import data to Cloud Databases. For example, for PostgreSQL, you can use pg_dump and pg_restore and, for MySQL, you can use mysqldump and mysqlimport.

Please refer to the official website for each DBMS documentation:

• MongoDB
• MySQL
• PostgreSQL
• Redis® open source

We are adding more and more Databases Management Systems over time. Please find the list and proposed versions in our Cloud Databases - Capabilities and Limitations guide.

Each software, including database software, provides newer versions of its code, usually including bug fixes, security enhancements, and improvements.

In general, a minor version upgrade includes only changes that are backward-compatible with existing applications. In contrast, a major version can bring incompatibilities.

Each DBMS acts differently and their official documentation is the source of truth.

You can create a DB instance via API or the OVHcloud Control Panel. In both cases, you can select various parameters such as DBMS type and DBMS versions.

Yes, when all the required conditions are met:

• when your service is up and running,
• when another DBMS version is available, and
• when the DBMS allows it.

If all the conditions are validated, you can perform the update directly via API or the OVHcloud Control Panel.

An update of a DBMS must always be tested, and a customer should follow the DBMS official best practices. Usually, new major versions introduce new features and deprecate a few others. Based on your usage, it could lead to an outage of your applicative code.

Yes. Once you have a DB instance up and running, you can restore a backup as a new DB instance (Fork).

During this process, you can select various options such as another version of your DBMS. Once you verified the correct usage of your new services, you can either keep it or delete it.

Since we provide hourly billing, this operation can be repeated as much as you need (and without a strong billing increase).

You will be warned to upgrade your version.

Each DBMS has its own specificities for extensions. As a general rule, we only provided officially supported extensions.

Please find the list and proposed versions in our Cloud Databases - Capabilities and Limitations guide.

Cloud Databases are billed with a "pay-as-you-go" model. The entire Public Cloud ecosystem allows you to create projects, attach a payment method to the project (credit card, PayPal, etc.), and finally launch various products and services inside this project.

You don't pay before using the service. At the end of the month, we summarize your spending in one bill per project. Cloud Databases are billed per hour, for the service range and flavor selected during DB instances creations. Each started hour is counted.

Cloud Databases pricing includes:

• Setup and management of the services.
• Selected amount of nodes and internal characteristics such as vCPU, RAM, and Storage.
• Ingress/Egress network traffic, based on the limits of our regional flavors.
• Backups (retention vary, see our capabilities).
• Logs and Metrics (retention vary, see our capabilities).
• When required, software licenses.

Our pricing does not include:

• Additional backup retention costs.
• Additional logs and metric retention costs.

Each DB instance billing:

• starts when the service is up and running. For example, if the service takes 5 minutes to start, you don't pay for this setup time.
• stops when you delete your service.

To select the right amount of compute, RAM, and storage, you will need to assess your needs.

If you already have database instances, you can check what is consumed today. For a new service, you will have to forecast your needs. Keep in mind that you can scale up or down your DB.

For each DB instance, you can:

• Select a higher service plan if required (Essential to Business or Enterprise, Business to Enterprise).
• Select a higher or lower range of compute and storage, provided that the new storage is enough to contain your data.

For each DB instance, you cannot:

• Select a lower service plan.

In most cases and if your plan supports high availability, your instance will remain available during the scaling. However, the status of your service will switch to "updating", preventing you from modifying your service (e.g.: adding a user).

We do not provide benchmark results so far for Cloud Databases. Each business use case is different, and benchmarks may strongly differ compared to your real-life use cases. Just keep in mind that our performance gaps are linear.

During the DB instance creation, you can select the region and data center to deploy your service. Please find the exact list in our Cloud Databases - Capabilities and Limitations guide.

To provide high availability, we use the clustering principles. Your service and your data are replicated across multiple nodes, preventing the overall system from a node failure. Your service is resilient mainly because we duplicated the data and configuration in multiple nodes.

The exact implementation may differ for each DBMS. Indeed, each DBMS has its own mechanisms and best practices.

For example:

• PostgreSQL or MySQL, it starts with 2 nodes.

For relational DBMS, such as MySQL and PostgreSQL, each node has a role:

• A primary node can accept READ and WRITE operations. It acts like the source of truth and is replicated to replica nodes.
• A replica node is a copy of the primary node from the data perspective and can accept READ operations only. Replica nodes are very helpful to achieve high availability but also improve READ performances.

In case of a Primary Node failure, a Replica can be elected as Primary.

Yes, in case of a node failure, the failover mechanism is automatic, whatever the DBMS is. OVHcloud is taking care of the failover process, new nodes are elected and promoted if necessary.

A failover is automatic but the whole process can take from a few seconds up to 1 minute.

In case of a failover, your cluster will be in degraded mode:

• READ operations can be performed as usual.
• WRITE operations will be discarded until the failover process is over.

Backups are performed differently according to the DBMS. See our Cloud Databases - Automated Backups guide for more details.

Yes, you can perform manual backups.

We use official and unmodified (vanilla) versions of DBMS, allowing you to rely on official documentation for each DBMS to perform backups for Cloud Databases. For example, for PostgreSQL, you can use pg_dump and pg_restore. For MySQL, you can use mysqldump and mysqlimport.

Please refer to the official website for each DBMS documentation:

• MongoDB
• MySQL
• PostgreSQL
• Redis® open source

No, you cannot directly download backups made by OVHcloud. But you can restore them to another service and then use official command lines to dump the data.

When possible, we store your encrypted backups outside the region of your service, for sustainability reasons. The location of the backup is available, along with all the other information about the backup, in the API.

The period during which the backup is stored depends on the plan you choose. You can find it in our Cloud Databases - Automated Backups guide.

As a customer, you are solely responsible for making the appropriate backups for your services.

The backup window is the period of the day during which the backup operations are executed. Your instance will remain available.

Yes, you can modify the backup window via the OVHcloud control panel, Terraform, or the API.

Yes, you can. Please refer to our Cloud Databases - Automated Backups guide for more details.

The maintenance window is the period of the day during which the maintenance operation, such as security patches, can be executed. Depending on the maintenance operation, your DB instance will or will not be available during this event, but in most cases, your instance will be available.

Yes, you can modify the maintenance window via the OVHcloud Control Panel, Terraform, or the API. See our Cloud Databases - Maintenance Operations guide for more information.

Each database instance is strongly secured through multiple actions:

• Infrastructure: We rely on OpenStack open-source software stack for our whole Public Cloud. We are audited by official organisms and certified with ISO27001 norms for example.
• Public or Private Network: Based on your needs and your internal policies about security, you can opt for public network access (Internet) or Private Network (vRack) access.
• Network ACL: We provide an Access Control List (ACL) allowing you to specify which IPs or IP blocks have the right to connect to your database instance. By default, no ACL is declared on the service meaning nobody can connect to your service until you add at least one.
• End-to-End Encryption: connections to databases are, by default, encrypted with TLS protocol, providing end-to-end encryption protection. OVHcloud generates an SSL/TLS certificate for each dB instance. Once you establish an encrypted connection between your application and your database instance, your data flows will be encrypted.
• Data Encryption: Data is stored on dedicated volumes that are encrypted.

Once you start a new database instance, the default values are:

• Zero access to IPs or IP ranges. Nothing is authorized (ACL).
• 1 user created (admin) but not configured. You have to reset the password.

Initially, your database cannot be accessed. It's made on purpose to protect your data from unsolicited connections.

Once your database instance is created, you can manage authorized IPs or IP blocks either in the OVHcloud Control Panel or via Terraform or the API. You need at least 1 authorized IP to access your service.

Please read our Getting Started with Cloud Databases guide to get step-by-step instructions.

Once your database instance is created, you can manage database users either in the OVHcloud control panel or via Terraform or the API. You need at least 1 created and configured user. Please read our Getting Started with Cloud Databases guide to get step-by-step instructions.

The volumes where the data is stored are encrypted and the backups are also encrypted before being stored.

Yes, all database instances can connect to the public network. It has to be specified and selected during database instance creation. If you select Public Network connectivity, you can not be connected through Private Network.

Yes, based on the service plan, database instances can connect to a private network (vRack). It has to be specified and selected during database instance creation. If you select Private Network connectivity, you can not be connected through Public Network.

No, you cannot. Once the networking type of an instance is set, you cannot switch to the other networking type. However, if your instance already has data and you want to move to the other networking type, you can restore your instance from a backup to a new instance with the other networking type (fork).

Currently, you cannot move your database from one vRack to another. You can follow our official roadmap.

Yes, inbound network traffic is included in our prices and not metered.

Yes, outbound network traffic is included in our prices and not metered. It allows you to benefit from predictive pricing, without any risks of uncontrolled billing increase.

Each database instance is secured by default.

To connect to a database instance, please make sure to:

• Have a database instance up and running. Be sure it's not in "maintenance" or "setting up" mode.
• Have at least one user configured (user login and password).
• Have a least one authorized IP. It has to be the IP that will access your database (your computer, your dedicated server, etc.). For troubleshooting purposes only, you can also add the "0.0.0.0" IP so that it will allow "any" connection. Remove it after your tests are done.
• Know your database instance connection parameters: host address, port, security mode.

Once you are ready, you can test the connection via the DBMS official command line interface or with classic application code such as Python, PHP, Java, etc. You can find connection examples in various languages in our Example Repository.

If you still have connectivity issues, please contact our support.

If you forgot your user credentials, or have security concerns, you can modify your user password directly via the OVHcloud Control Panel in the "Users & Roles" section. It will log out existing connections instantiated by this user.

Each database instance has a limited amount of storage space. We recommend you monitor your remaining storage space constantly.

To manage storage issues, please refer to the Cloud Databases - Handling "Disk Full" Situations guide.

Queries are operations performed on your database instances, such as READ operations, WRITE operations, or DELETE operations.

These query performances are related to many external factors:

• Your data schema. The organization of your data will strongly impact your performance.
• The amount of data to query. A query on 1 table of 1000 lines is different from a query on 20 tables of 1 million lines.
• The quality of your application code.
• The flavor performance: Each flavor has its own hardware specifications. The more RAM and vCPU you have, the more efficient queries will be.
• The heavy usage of the service (for example legitimate traffic due to Sales actions).
• An issue on the hardware infrastructure or network.

To troubleshoot your performance, the first step is to check if the service is not affected, i.e. by a travaux task. To bench a superior flavor, you can duplicate your database instance to a higher flavor model and test again the performance.

Overall, if you are experiencing punctual slowness, you need database and system admin skills.

If your data is corrupted, you have two options:

• If your data are important, you can restore a backup where your data is valid. You need to investigate on your own for this step.
• If your data can be deleted, you can delete the database instance service and create a new one, or just follow official the DBMS documentation to delete all the data.