Skip to content

Matches page titles and page text. Forty pages, indexed at build time.

Versions and upgrades

PostgreSQL 16, 17 and 18 are supported. The major is fixed for the life of a service, how to move to a newer one, and when a major is retired.

A service runs PostgreSQL 16, 17 or 18, chosen when it is created. New services default to 18.

The major version is fixed for the life of a service. Moving to a newer major means a new service and a cutover you plan.

Check what you are running

  1. Open the service. The minor version installed on its host is shown on the service page, and in the services list.

Or ask the server:

sql
SELECT version();
SHOW server_version;

Move to a newer major

  1. Create a new service on the target version. See create your first service.

  2. Take a dump from the old service, using the pg_dump from the newer version:

    bash
    pg_dump --format=custom --no-owner --no-privileges --file=appdb.dump \
  "postgresql://[email protected]:25439/appdb?sslmode=verify-full&sslrootcert=system"

  3. Create your roles on the new service, then restore:

    bash
    pg_restore --dbname="postgresql://[email protected]:25441/appdb?sslmode=verify-full&sslrootcert=system" \
  --no-owner --no-privileges --jobs=4 appdb.dump

  4. Run ANALYZE on the new service.

  5. Check your application against it.

  6. Point your application at the new service.

The two ports above are different because the two services are. Each service is given its own pair in its location, and each one is on that service's Connect tab. Both commands use the direct port, so a long dump or restore does not occupy a pooled server connection for its duration.

Plan the cutover as downtime. Anything written to the old service after the dump is not in the new one. The full command set, including the flags that matter, is on dump and restore.

Before you move

  • Check every extension you use is in the supported extensions catalogue, and that the extension itself supports the target version.
  • Read the upstream release notes for behaviour changes, especially around planner defaults.
  • Take an export first, so the point immediately before the move is trivially recoverable. See exporting.
  • Rehearse the dump and restore into a spare service, and run your application against it before the real cutover.

Minor updates

Minor releases are bug and security fixes and do not change on-disk format. Applying one means installing the new binaries and restarting the service, so it is planned work: announced at least 72 hours ahead and run inside the service's maintenance window. See maintenance windows.

End of support

We support the three newest PostgreSQL majors. Upstream supports each major for five years, and a major is supported here for as long as it receives upstream security fixes. A major is retired only after its upstream end of life, with at least six months' notice and a supported way to upgrade off it.

What you will see

A restore into a new major reports nothing unusual if your schema is portable. Read the last line of pg_restore output: it carries on past a failed statement by default and reports how many errors it ignored at the very end, so a partial restore can look finished.

text
pg_restore: warning: errors ignored on restore: 3

Three ignored errors is a restore you have to inspect, not a restore that worked.

Troubleshooting

pg_restore reports ignored errors. Read them. The usual causes are an extension not in the catalogue, an object owned by a role that does not exist on the target, or something needing superuser. See compatibility notes.

unsupported version in file header. The dump was taken with a pg_dump older than the target server. Use a pg_dump at least as new as the server you are restoring into.

Queries are slower on the new service. Run ANALYZE. A freshly restored database has no statistics, and "the new database is slow" is nearly always this.

Text sorts differently after the move. A collation change alters sort order. See compatibility notes.