One-click upgrade your PostgreSQL to version 10.1 now available!

Upgrade Process

As a preamble, let's have a look at how to upgrade your database on Scalingo. As usual, the upgrading process on Scalingo is as simple as clicking a button on the database dashboard. The following picture shows the message you will see on your database dashboard if you are running the latest 9.6 version (i.e. PostgreSQL v9.6.5):

This upgrade can take some time for the biggest databases. During the process, your database will be taken offline. You will first have to upgrade to the latest 9.6.5-2 before being able to upgrade to 10.1.

As usual, you can find the corresponding Docker images on our Docker Hub repository.

We strongly advise you to test that your code still works with the new database version. To ease this task, you can pull the PostgreSQL version you need from our public Docker Hub repository and test locally your code. You can also get the same container that we've built for your app and that's running on our infrastructure using our Docker Image Addon.

We can now have a look at the new features introduced in PostgreSQL 10.1.

What is New on PostgreSQL 10.1

After one year of development, the PostgreSQL Global Development Group just released the version 10 of their database. This version announces some great features in the area of high availability and performance.

PostgreSQL High Availability

PostgreSQL databases have had high availability capability for a long time. This latest release of PostgreSQL adds a "Logical Replication" feature to ease the replication of only a part of the primary server and adds the possibility to write on the secondary server.

You can get more thorough explanation on this feature in this blog post by Petr Jelinek.

Speaking of high availability, benefiting from the work on MongoDB replica set, we are working on high availability for PostgreSQL. Stay tuned!

PostgreSQL performance

PostgreSQL 9.6 introduced parallel query for faster execution. In version 10, the team kept working on this feature. More part of the query execution process are parallelized leading to even more performance when leveraging such feature.

The following simple example shows how to parallelize the execution of a query. Let's first execute a query without parallelizing the query execution:

accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 group by bid;
...
Time: 324.903 ms

We now set the maximum number of parallel workers to 4 and watch the brilliant result:

accounts=# set max_parallel_workers_per_gather=4;
SET
Time: 0.822 ms
accounts=# SELECT bid, count(*) FROM account_history
                        WHERE delta > 1000 GROUP BY bid;
...
Time: 72.864 ms

From 324 ms to 72 ms, not bad!

For more technical details on this great improvement, you can read this blog post.

Version Numbering

Lastly, on a non-technical side, PostgreSQL no longer uses version numbers with 3 digits but is shifting to a 2 digits numbering. This means that the next major version will be 11 and 10.1 is the first patch to PostgreSQL 10.

For a comprehensive list of what is new in PostgreSQL 10, please refer to this blog post from the official website.

The version 10.1 is already in production at Scalingo. It contains three important security fixes as stated in this official blog post.