Tiger Cloud: Performance, Scale, Enterprise

Self-hosted products

MST

Tiger Cloud offers managed database services that provide a stable and reliable environment for your applications. Each service is based on a specific version of the PostgreSQL database and the TimescaleDB extension. To ensure that you benefit from the latest features, performance and security improvements, it is important that your Tiger Cloud service is kept up to date with the latest versions of TimescaleDB and PostgreSQL.

Tiger Cloud has the following upgrade policies:

  • Minor software upgrades: handled automatically, you do not need to do anything.

    Upgrades are performed on your Tiger Cloud service during a maintenance window that you define to suit your workload. You can also manually upgrade TimescaleDB.

  • Critical security upgrades: installed outside normal maintenance windows when necessary, and sometimes require a short outage.

    Downtime is usually between 30 seconds and 5 minutes. TigerData aims to notify you by email if downtime is required, so that you can plan accordingly. However, in some cases this is not possible.

  • Major upgrades: such as a new version of PostgreSQL are performed manually by you, or automatically by Tiger Cloud.

Important

After a maintenance upgrade, the DNS name remains the same. However, the IP address often changes.

If you do not manually upgrade TimescaleDB for non-critical upgrades, Tiger Cloud performs upgrades automatically in the next available maintenance window.

Most upgrades that occur during your maintenance windows do not require any downtime. This means that there is no service outage during the upgrade. However, all connections and transactions in progress during the upgrade are reset. Usually, the service connection is automatically restored after the reset.

Some minor upgrades do require some downtime. This is usually between 30 seconds and 5 minutes. If downtime is required for an upgrade, TigerData endeavors to notify you by email ahead of the upgrade. However, in some cases, we might not be able to do so. Best practice is to schedule your maintenance window so that any downtime disrupts your workloads as little as possible and minimize downtime with replicas. If there are no pending upgrades available during a regular maintenance window, no changes are performed.

To track the status of maintenance events, see the Tiger Cloud status page.

Maintenance upgrades require up to two automatic failovers. Each failover takes less than a few seconds. Tiger Cloud services with high-availability replicas and read replicas require minimal write downtime during maintenance, read-only queries keep working throughout.

During a maintenance event, services with replicas perform maintenance on each node independently. When maintenance is complete on the primary node, it is restarted:

  • If the restart takes more than a minute, a replica node is promoted to primary, given that the replica has no replication lag. Maintenance now proceeds on the newly promoted replica, following the same sequence. If the newly promoted replica takes more than a minute to restart, the former primary is promoted back. In total, the process may result in up to two minutes of write downtime and two failover events.
  • If the maintenance on the primary node is completed within a minute and it comes back online, the replica remains the replica.

Non-critical upgrades are available before the upgrade is performed automatically by Tiger Cloud. To upgrade TimescaleDB manually:

  1. Connect to your service

    In Tiger Cloud Console, select the service you want to upgrade.

  2. Upgrade TimescaleDB

    Either:

    • Click SQL Editor, then run ALTEREXTENSION timescaledb UPDATE.
    • Click , then Pause and Resume the service.

To ensure you benefit from the latest features, optimal performance, enhanced security, and full compatibility with TimescaleDB, Tiger Cloud supports a defined set of PostgreSQL major versions. To reduce the maintenance burden and continue providing a high-quality managed experience, as PostgreSQL and TimescaleDB evolve, TigerData periodically deprecates older PostgreSQL versions.

TigerData provides advance notification to allow you ample time to plan and perform your upgrade. The timeline deprecation is as follows:

  • Deprecation notice period begins: you receive email notification of the deprecation and the timeline for the upgrade.
  • Customer self-service upgrade window: best practice is to manually upgrade to a new PostgreSQL version in this time.
  • Automatic upgrade deadline: Tiger Cloud performs an automatic upgrade of your service.

Upgrading to a newer version of PostgreSQL enables you to take advantage of new features, enhancements, and security fixes. It also ensures that you are using a version of PostgreSQL that's compatible with the newest version of TimescaleDB.

For a smooth upgrade experience, make sure you:

  • Plan ahead: upgrades cause downtime, so ideally perform an upgrade during a low traffic time.
  • Run a test upgrade: fork your service, then try out the upgrade on the fork before running it on your production system. This gives you a good idea of what happens during the upgrade, and how long it might take.
  • Keep a copy of your service: if you're worried about losing your data, fork your service without upgrading, and keep this duplicate of your service. To reduce cost, you can immediately pause this fork and only pay for storage until you are comfortable deleting it after the upgrade is complete.
Important

Tiger Cloud services with replicas cannot be upgraded. To upgrade a service with a replica, you must first delete the replica and then upgrade the service.

The following table shows you the compatible versions of PostgreSQL and TimescaleDB.

TimescaleDB versionPostgreSQL 17PostgreSQL 16PostgreSQL 15PostgreSQL 14PostgreSQL 13PostgreSQL 12PostgreSQL 11PostgreSQL 10
2.20.x
2.19.x
2.18.x
2.17.x
2.16.x
2.15.x
2.14.x
2.13.x
2.12.x
2.10.x
2.5 - 2.9
2.4
2.1 - 2.3
2.0
1.7

We recommend not using TimescaleDB with PostgreSQL 17.1, 16.5, 15.9, 14.14, 13.17, 12.21.
These minor versions introduced a breaking binary interface change that, once identified, was reverted in subsequent minor PostgreSQL versions 17.2, 16.6, 15.10, 14.15, 13.18, and 12.22. When you build from source, best practice is to build with PostgreSQL 17.2, 16.6, etc and higher. Users of Tiger Cloud and platform packages for Linux, Windows, MacOS, Docker, and Kubernetes are unaffected.

For more information about feature changes between versions, see the PostgreSQL release notes and TimescaleDB release notes.

Warning

Your Tiger Cloud service is unavailable until the upgrade is complete. This can take up to 20 minutes. Best practice is to test on a fork first, so you can estimate how long the upgrade will take.

To upgrade your service to a newer version of PostgreSQL:

  1. Connect to your service

    In Tiger Cloud Console, select the service you want to upgrade.

  2. Disable high-availability replicas

    1. Click Operations > High Availability, then click Change configuaration.
    2. Select Non-production (No replica), then click Change configuration.
  3. Disable read replicas

    1. Click Operations > Read scaling, then click the trash icon next to all replica sets.
  4. Upgrade PostgreSQL

    1. Click Operations > Service Upgrades.
    2. Click Upgrade service, then confirm that you are ready to start the upgrade.

    Your Tiger Cloud service is unavailable until the upgrade is complete. This normally takes up to 20 minutes. However, it can take longer if you have a large or complex service.

    When the upgrade is finished, your service automatically resumes normal operations. If the upgrade is unsuccessful, the service returns to the state it was in before you started the upgrade.

  5. Enable high-availability replicas and replace your read replicas

If you do not manually upgrade your services within the customer self-service upgrade window, Tiger Cloud performs an automatic upgrade. Automatic upgrades can result in downtime, best practice is to manually upgrade your services during a low-traffic period for your application.

During an automatic upgrade:

  1. Any configured high-availability replicas or read replicas are temporarily removed.
  2. The primary service is upgraded.
  3. High-availability replicas and read replicas are added back to the service.

When you are considering your maintenance window schedule, best practice is to choose a day and time that usually has very low activity, such as during the early hours of the morning, or over the weekend. This helps minimize the impact of a short service interruption. Alternatively, you might prefer to have your maintenance window occur during office hours, so that you can monitor your system during the upgrade.

To change your maintenance window:

  1. Connect to your service

    In Tiger Cloud Console, select the service you want to manage.

  2. Set your maintenance window

    1. Click Operations > Environment, then click Change maintenance window.
      Maintenance and upgrades
    2. Select the maintence window start time, then click Apply.

    Maintenance windows can run for up to four hours.

Keywords

Found an issue on this page?Report an issue or Edit this page in GitHub.