For AI agents: the complete documentation index is at llms.txt. Every page is also available as markdown by appending .md to its URL, or by sending an Accept: text/markdown request header.

Upgrade QuestDB

Upgrading QuestDB to a newer version requires replacing the server binary (or pulling a new Docker image) and restarting the process. Your existing data directory stays in place. This applies to both QuestDB Open Source and QuestDB Enterprise.

Looking for a fresh install?

If this is your first time setting up QuestDB, see the Quick start guide instead.

Before you upgrade​

  1. Read the release notes. QuestDB is generally backwards compatible, but breaking changes do occur and are documented in the release notes.

  2. Back up your data. On first startup, the new version may automatically migrate internal metadata. Once this happens, rolling back to the previous version may produce errors. Create a backup or snapshot before upgrading, especially for production instances. See Backup and restore for details.

Upgrade steps​

Docker​

Pull the latest image and restart the container, pointing to the same data volume:

docker pull questdb/questdb:latest

Then recreate your container with the new image, using the same volume mount for your QuestDB root directory:

docker stop questdb
docker rm questdb
docker run -d --name questdb \
  -p 9000:9000 -p 9009:9009 -p 8812:8812 \
  -v /path/to/questdb-data:/var/lib/questdb \
  questdb/questdb:latest

Replace /path/to/questdb-data with the path to your existing data directory.

Binaries​

  1. Stop the running QuestDB process.
  2. Download the new binary from the GitHub releases page (or build from source).
  3. Replace the old binary with the new one.
  4. Start QuestDB, pointing to the same root directory.

QuestDB Enterprise​

QuestDB Enterprise BYOC

If you are a QuestDB Enterprise BYOC customer, upgrades are managed for you. See QuestDB Enterprise BYOC below.

The upgrade process for Enterprise is identical: replace the binary or pull the new image, then restart.

The difference is how you obtain the new version:

  • Binaries: download from the SFTP or distribution channel provided by QuestDB during onboarding.
  • Docker: pull from the Enterprise ECR registry that was whitelisted for your AWS account.

If you are unsure where to get the latest Enterprise version, contact support@questdb.com.

Replication: upgrade order​

When running QuestDB Enterprise with replication, upgrade all replicas before upgrading the primary.

The primary may write WAL segments containing new metadata formats to the object store. If a replica running an older version encounters metadata it does not recognize, it will error. Upgrading replicas first ensures they can handle any new metadata the primary produces after its upgrade.

When upgrading to 4.0.0 or later, grant the SWITCH ROLE permission only after every node runs the new version. The permission is stored in a form older versions cannot read. A principal that holds DATABASE ADMIN, including through a database-level GRANT ALL issued on 2.3.1 or later, already has it. Others, such as accounts that triggered role switches through SYSTEM ADMIN on 3.3.x, need an explicit GRANT SWITCH ROLE. See Failover operator and Database administrator.

Upgrading to 4.1.0​

QuestDB Enterprise 4.1.0 hides tables and views from principals that hold no permission on them, see object visibility. The behavior applies whenever access control is enabled and cannot be turned off. Check the following before upgrading:

  • Catalogue queries such as tables() and SHOW TABLES list only the objects a principal holds a permission on. Statements that name any other object fail with the missing-object error, such as table does not exist [table=trades], instead of Access denied. Update clients and tests that match the old message.
  • reader_pool(), writer_pool(), files(), and glob() with a pattern outside cairo.sql.copy.root require SYSTEM ADMIN. Monitoring accounts that call them need it, which also makes every unprotected object visible to them.
  • Monitoring accounts that poll tables() or wal_tables(), for example to detect suspended tables, see only the tables they hold a permission on, so a suspended table hidden from them raises no alert. Grant such an account SYSTEM ADMIN, or a permission on every table it watches, see monitoring account. Only SYSTEM ADMIN and DATABASE ADMIN holders also see the protected access control tables in wal_tables().
  • Creating a materialized or live view that calls a catalogue function, such as tables(), requires SYSTEM ADMIN. An existing materialized view that reads one through a regular view is invalidated at its first refresh.
  • Existing materialized and live views that call a catalogue function in their own query keep refreshing, even when their creator does not hold SYSTEM ADMIN. Their refresh sees every object, so every principal with SELECT on such a view reads what the function lists, including objects hidden from it. Review who can read these views, and drop or rewrite the ones whose readers should not see every object.
  • A view created on an earlier version that calls a table-name function, such as table_columns('trades'), resolves that table with the permissions of each reader. A reader that holds no permission on the table gets table does not exist from the view until you redefine the view after the upgrade, see metadata functions in views.
  • Compiled statements in the query caches are no longer shared between principals, so cache hit rates can drop when many principals run the same SQL.

QuestDB Enterprise BYOC​

For QuestDB Enterprise BYOC customers, QuestDB manages the upgrade process. The QuestDB team will reach out to coordinate when a new version is available. If you would like to upgrade sooner, contact support@questdb.com.