You applications need databases to store your data. As we believe your data should be located geographically close to your application servers we support the most common types of database.
We ensure your database is located at the same location as your applications. It provides the best performance and latency possible. Moreover you know where your data are.
Backups Retention Policy
If your database is in a paid plan (i.e. it’s not “free plan”), we’ll automatically make periodic backups of your database on a daily basis, at around 1:00 AM Central European Time (CET or UTC+0100). The time of your daily backup is configurable via the web dashboard of your database or using the CLI. The scheduled date is not strongly enforce: it might get delayed depending on the load on our infrastructure.
We keep a limited amount of backups depending on your database plan. A daily backup is retained for the last 7 days. That means that 7 backups will exist, one for each of the last 7 days. A weekly backup means that only one backup is saved over a 7 days period. A monthly backup means that only 1 backup is saved over the course of a month.
|Plan||Weekly Backups Retained||Monthly Backup Retained|
|Starter||4 weeks||0 months|
|Business||8 weeks||12 months|
You can also manually trigger a backup for your database at any time you want. The number of manual backups that you can retain is limited by your plan:
In case a database is removed from an application, the retention policy remains untouched: backups are not instantly deleted.
Encryption at Rest
All databases created after the 6th of January 2019 have encryption at rest enabled. In other words, all your data is encrypted before being stored on disk.
Encryption at rest on our database offer leverages a feature of the Linux Kernel
allowing to encrypt data at the disk level named
dm-crypt. The algorithm used
aes-xts-plain64 with a key size of 256 bit and hashed using SHA-256. This
method is considered secure and standard in the industry. To reduce the attack
surface, each instance of each database has its own cryptographic key to protect
its data, so getting access to one key wouldn’t allow an attacker to get plain
data from another database. The keys are stored in a database which is itself
encrypted and protected by authentication.
Communication With TLS
We enable for all database types the possibility to connect to them using TLS. By default, you can connect both with or without TLS to your database. You can also enforce all connections to use TLS by activating the “Force TLS Connections” feature in the web dashboard of your addon:
Moreover, we also encrypt all communications between the members of cluster:
- from the gateways to the leader,
- from the leader to the followers,
- between the cluster orchestrator and its database for PostgreSQL databases.
Most of our high availability setups contain a HAProxy as entry point to the actual database nodes. This HAProxy has a few timeouts configured which may impact your application, especially if you reuse connections. The concerned databases are:
- Timeout when the client is inactive: 1 minute.
- Timeout when the server is inactive: 2 minutes.
- Maximum allowed time to wait for a complete HTTP request: 5 seconds.
- Timeout when the client is inactive: 1 day.
- Timeout when the server is inactive: 30 minutes.
- Inactivity timeout on the client side for half-closed connections: 5 minutes.
- Timeout when the client is inactive: 5 minutes.
- Timeout when the server is inactive: 5 minutes.
- Inactivity timeout on the client side for half-closed connections: 1 hour.