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.

Database Plans

Scalingo offers three classes of service with distinct characteristics, enabling you to choose the level of performance, replication, security and price that suits your use case. All our plans are 100% managed and billed on demand.

You can seamlessly switch between plans and service classes in just a few seconds, from the smallest single-node instance plan to the largest multi-node cluster plan, and everything in between.

Sandbox

The Sandbox class is designed for testing and development environments. It is ideal for evaluating our service or testing new technology.

It is not suitable for hosting production workloads due to its performance limitations and lack of guaranteed availability and backups.

Starter

The Starter class is designed for applications under development and production in non-critical environments. With an SLA of 98% and back-up retention of one month, it offers a secure, high-performance environment for a wide range of use cases.

Business

Scalingo’s flagship, the Business class, guarantees the high availability and reliability essential for critical production applications. Thanks to hot replication of your data on a stand-by node, we ensure service continuity along with a 99.96% SLA. For complete protection, backup retention is extended to 1 year.

Database Types

SQL

• Scalingo for PostgreSQL®
• Scalingo for MySQL®

NoSQL

• Scalingo for MongoDB®
• Scalingo for Redis®
• Scalingo for Elasticsearch®
• Scalingo for InfluxDB®

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 enforced: it might get delayed depending on the load on our infrastructure.

Using the Database Dashboard

1. From your web browser, open your database dashboard
2. Click the Backups tab
3. Locate the Backup schedule block
4. Click the Schedule button
5. Make sure to check the I want to enable scheduled backups checkbox
6. Pick an hour (timezone is UTC)
7. Validate by clicking the Update button

Using the Command Line

1. Make sure you have correctly setup the Scalingo command line tool
2. Configure the time of backup:
   • By setting an hour:

     scalingo --app my-app --addon [YOUR ADDON KIND] backups-config --schedule-at 3
     

     In this example, we ask the platform to create the backups at ~03:00. Note: The timezone used is the local timezone of the machine running the command.

   • By setting an hour and a timezone:

     scalingo --app my-app --addon [YOUR ADDON KIND] backups-config --schedule-at "4:00 UTC"
     

     In this example, we ask the platform to create the backup at ~04:00 UTC. The output should look like this:

     -----> Periodic backups will be done daily at 6:00 CET
     

Retention Policy for Daily Backups

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.

Retention Policy for Manual Backups

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.

Creating a Manual Backup

Using the Database Dashboard

1. From your web browser, open your database dashboard
2. Click the Backups tab
3. Locate the Backup Settings block
4. Click the Make Manual Backup button
5. Locate the Backups block
6. Click the Trigger manual backup button

Using the Command Line

1. Make sure you have correctly setup the Scalingo command line tool
2. Ask the platform to backup the database:

   scalingo --app my-app --addon [YOUR ADDON KIND] backups-create
   

   After a while, the output should look like this:

   -----> Backup successfully finished
   

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 is 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.

Connection Timeouts

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:

• Scalingo for Elasticsearch®:
  • 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.
• Scalingo for PostgreSQL®:
  • 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.
• Scalingo for Redis®:
  • 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.