Frequently Asked Questions on Public Cloud Databases
Frequently Asked Questions on Public Cloud Databases
Last updated August 25th, 2021
Here are the most frequently asked questions about Public Cloud Databases.
Public Cloud Databases is a managed service allowing you to deploy and use databases 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 network, observability tools such as logs and metrics, and end-to-end security mechanisms.
Our Public 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 baremetal, Hosted Private Cloud, OVHcloud VPS... but also allow for Hybrid Cloud as long as you can use Public network (Internet).
Enterprise Cloud Databases is only providing the PostgreSQL database engine, and is powered by dedicated servers. Public Cloud Databases are based on virtual machines, and provides multiples DBMS.
Enterprise Cloud Databases will smoothly be transited to Public Cloud Databases in the near future.
Major differences with our Web Hosting Databases are the ability to connect to public and private networks, native integration in Public Cloud with pay-as-you-go, bigger range of compute, and improved resiliency with clustering. Also, Public Cloud Databases will provide more DBMS possibilities.
We are adding more and more Databases Management Systems over time, please find the exact list and proposed versions in our Capabilities page.
Yes. Public Cloud databases can be connected to Public network (Internet) or Private network (vRack).
You can then connect them to any product compliant with these network topologies:
Yes. You can reach your Public Cloud Databases services with 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 label such as "Databases".
We built service plans based on business use-cases. They have major differentiators, related to each DBMS.
Overall, we designed 3 services plans with these usages in mind:
OVHcloud manages various tasks on your behalf:
Still, since we provide a database access, as a customer you are responsible for managing the services:
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 of your history. The default quota is limited to 20 instances per project.
Public Cloud Databases require a Public Cloud project. Once a project is created, you can start databases instances via the OVHcloud Control Panel in few minutes.
Please read our Getting started with Public Cloud Databases documentation.
We use official and un-modified (vanilla) versions of DBMS, allowing you to rely on official documentation for each DBMS to import data to Public Cloud Databases. For example, for PostgreSQL you are able to use pg_dump and pg_restore, for MySQL you can use mysqldump and mysqlimport.
Please refer to the offical website for each DBMS documentation:
We are adding more and more Databases Management Systems over time, please find the exact list and proposed version in our Capabilities page.
Each software, including database software, provides newer versions of their 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 are able to select various parameters such as DBMS type and DBMS versions.
Yes, when all the required conditions are met:
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 before, and a customer should follow the DBMS official best practices. Usually, new major versions introduce new features and deprecate few others. Based on your own 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 are able to 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 in order to upgrade your version.
Each DBMS has its own specificities for extensions. As a general rule, we only provided officialy supported extensions.
Please find the exact list and proposed version in our Capabilities page.
Public Cloud Databases are billed with a "pay-as-you-go" model. The entire Public Cloud ecosystem allows you to create projects, then attach a payment method to the project (credit card, PayPal, ...) 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 spendings in one bill per project. Public Cloud Databases are billed per hour, for the service range and flavor selected during DB instances creations. Each started hour is counted.
Inside the Public Cloud section of the OVHcloud Control Panel, please find the "Project Management" category. The "Billing Control" sub-section allows you to view the current consumption for each product such as Public Cloud Databases, but also to search for previous bills in your history.
Public Cloud Databases pricing includes:
Our pricing does not include:
Each DB instance billing:
We are based on UTC Time.
To select the right amount of compute, RAM and storage, you will need to assess your needs.
If you already have databases instances, you can check what is consumed today. For a new service, you will have to forecast you needs. Keep in mind that you can upgrade your DB instance range to a bigger one.
For each DB instance, you can:
For each DB instance, you can not:
In most cases, 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 benchmarks results so far for Public Cloud databases. Each business use-case is different, and benchmarks may strongly differ compared to your own real-life use-cases. Just keep in mind that our performances gaps are linear.
During the DB instance creation, you can select the region and datacenter to deploy your service. Please find the exact list and proposed version in our Capabilities page.
So far we do not provide Multi-AZ deployments. We included this option in our backlog, you can follow its implementation in our official roadmap.
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 MongoDB, High-Availability starts with 3 nodes. For PostgreSQL or MySQL, it starts with 2 nodes.
For relational DBMS, such as MySQL and PostgreSQL, each node has a role:
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:
Backups are performed differently according to the DBMS. For MongoDB, a mongodump is executed, encrypted and stored on our infrastructure.
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 Public Cloud Databases. For example, for PostgreSQL you are able to use pg_dump and pg_restore. For MySQL you can use mysqldump and mysqlimport.
Please refer to the offical website for each DBMS documentation:
No, you can not directly download backups made by OVHcloud. But you can restore them to another service and then use offical 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 with all the other information of the backup in the API.
The period during which the backup is stored depends on the plan you subscribed. You can find it in our Capabilities page.
As a customer, you are solely responsible to make the appropriate backups for your services.
The maintenance window is the period of the day during which the maintenance operation, such as the backups, 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.
Currently you can not modifiy the maintenance window. Please follow our official roadmap.
Each database instance is strongly secured through multiple actions:
Once you start a new database instance, the default values are:
To sum-up, 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 through the OVHcloud Control Panel or via API. You need at least 1 authorized IP to access your service.
Please read our Getting started guide to get a step by step documentation.
Once your database instance is created, you can manage database users through the OVHcloud control panel or via API. You need at least 1 created and configured user. Please read our Getting started guide to get a step by step documentation.
The volumes where the data is stored are encrypted and the backups are also encrypted before being stored.
OVHcloud is meeting the highest standards certifications. Public Cloud Databases benefit from multiple certifications:
Yes, all databases instances have the ability to 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, databases instances have the ability to connect to 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.
At this time, you can not 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 a predictive pricing, without any risks of uncontrolled billing increase.
Exceptions: for databases instances located in APAC (Sydney, Singapore), inbound/outbound network is capped. This information is shown in the website pricing page.
Each database instance is secured by default.
To connect to a database instance, please make sure to:
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...
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 instanciated by this user.
Each database instance has a limited amount of storage space. We recommend you to monitor your remaining storage space constantly.
To prevent storage issues, OVHcloud:
If you are running out of storage, you can:
Queries are operations performed on your databases instances, such as READ operations, WRITE operations, or DELETE operations.
These queries performances are related to many external factors:
To troubleshoot your performance, usually 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 databases and system admin skills.
If your data is corrupted, you have 2 options:
We would love to help answer questions and appreciate any feedback you may have. Join our community of users on https://community.ovh.com/en/.
Are you on Discord? Connect to our channel at https://discord.gg/PwPqWUpN8G and interact directly with the team that builds our databases service!
Please feel free to give any suggestions in order to improve this documentation.
Whether your feedback is about images, content, or structure, please share it, so that we can improve it together.
Your support requests will not be processed via this form. To do this, please use the "Create a ticket" form.
Thank you. Your feedback has been received.
Access your community space. Ask questions, search for information, post content, and interact with other OVHcloud Community members.Discuss with the OVHcloud community