Tarantool 3.9

Release date: 2026-10-30

Releases on GitHub:

• v. 3.9.0

The 3.9 release of Tarantool adds the following main product features and improvements for the Community Edition:

• Community Edition (CE)

  • SSL/TLS support and pap-sha256 authentication available in the Community Edition
  • Application threads as a stable feature

• Enterprise Edition (EE)

  • Configurable jitter for smooth configuration updates in big-sized clusters
  • Two-phase update process for SSL certificates
  • Configurable alerts for expiring SSL certificates
  • Multikey and functional multikey indexes supported by memtx MVCC

SSL/TLS encryption and pap-sha256 authentication are now available in the Community Edition. Before this release, these features were supported only by the Enterprise Edition. The only exception is for GOST cipher suites, which remain available only in the Enterprise Edition.

Application threads allow application code to use additional threads for offloading work from the main thread. Like the main thread, each application thread runs an independent event loop and a Lua interpreter and has most Tarantool built-in modules available.

For interacting with application threads, the threads module was introduced.

Application threads first appeared in Tarantool 3.7 as an experimental feature. In Tarantool 3.9, the threads module was moved out of the experimental namespace and the entire application threads feature is now considered stable.

The new config.reload_jitter parameter sets an interval (in seconds) for configrutation reload. Within this interval an instance randomly picks up a moment to fetch a new configuration from a remote storage (etcd or TbCS). This is necessary for smooth configuration updates in big-sized clusters. With this logic, instances do not fetch the configuration simultaneously (which would cause a load spike), but rather apply the new configuration more or less within the same time interval.

This option affects only the automatic reload from a remote source; an explicit call to config:reload() is not deferred and immediately ends the current interval.

When changing the certificate used to connect to the replica set instances (when changing the URI, including SSL parameters, in the iproto.listen/replication configuration), the instance now:

1. Applies the new iproto.listen immediately — this way, the new certificate immediately starts serving incoming requests.
2. Postpones reconnect replication to new URIs for a time interval (this interval is calculated based on a handful of configuration paramaters, see config.reload_jitter for details).

This gives other instances time to start servicing the new certificates before the current instance reconnects to them via replication — that is, we have a two‑phase certificate update: first, an update for the listening socket (iproto.listen), then, with a delay, an update for the outgoing connections (replication).

Another improvement to SSL certificate management in this release brings about periodical alerts for any problems with SSL certificate files used for encrypted connections. The alerts are configured in config.etcd.ssl.ssl_cert, SSL-enabled config.storage.endpoints, and failover.iproto.ssl.ssl_cert. A check runs every 12 hours and immediately after configuration reload. It warns no later than 30 days before expiration and keeps warning after expiration. The first certificate in each PEM file is checked. See Monitoring SSL certificate expiration for details.

Since this release, multikey and functional multikey TREE indexes are supported when the memtx transaction manager is enabled, with the same isolation guarantees as other TREE indexes.