12 November 2026 · 3 MIN READ

TimescaleDB 2.32.0 Released: Adaptive Integer Compression by Default, Security Fixes, and More

TimescaleDB 2.32.0 shipped today (Nov 12, 2026) with Adaptive Integer Compression enabled by default, major security hardening, faster continuous aggregates, and critical concurrency fixes.

TimescaleDBPostgreSQLHistoriansIIoTCompression
Grafana time-series monitoring dashboard displaying system metrics and graphs
Time-series telemetry visualization in Grafana. Screenshot: Linux Screenshots (CC BY 2.0).

Today, November 12, 2026, the Timescale team shipped TimescaleDB 2.32.0. For Industrial IoT (IIoT) and operational technology teams running TimescaleDB as a process historian or telemetry backend, this is an especially notable release: it combines a major compression milestone with a substantial set of security hardening and data-integrity fixes.

Here is a breakdown of what landed in 2.32.0 and why it matters in production.

1. Adaptive Integer Compression (AIC) Is Now On by Default

Previewed in 2.31.0, Adaptive Integer Compression (AIC) is now enabled by default in 2.32.0, replacing DeltaDelta as the default compressor for integer columns.

In industrial and IIoT schemas, tables rarely hold only smooth floating-point sensor readings—they are packed with integer status codes, device IDs, fault flags, counters, and discrete PLC registers. Traditional DeltaDelta compression struggles with those non-monotonic integer patterns and cannot vectorize decompression efficiently.

AIC evaluates each block of up to 256 integer values and selects the fastest-decompressing encoding (such as Frame of Reference, Patched FOR, Dictionary, or RLE). In Timescale's benchmarks, this yields:

  • ~50% better compression on integer columns (~10% overall database size reduction depending on schema).
  • ~50% faster typical analytical queries and 5–7x faster integer decompression.

Existing compressed chunks remain readable as-is; newly compressed chunks automatically use AIC, and older chunks can be recompressed if you want the space and read-speed gains retroactively.

2. Security Hardening & Least-Privilege Background Workers

The 2.32.0 release notes emphasize that this version includes a larger set of security fixes than usual stemming from proactive security reviews, with a recommendation to upgrade promptly:

  • No More Superuser for Background Worker Scheduling (#10983, #10953): The background worker scheduler now runs as the database owner rather than superuser, and database owners can start, stop, and restart background workers without superuser privileges.
  • Tighter Ownership & Permission Checks (#10966, #10993, #10919): Chunk operations now require ownership of the chunk (not just the hypertable), continuous aggregate creation checks schema CREATE privileges, and database commands verify ownership before stopping workers.
  • Safer Telemetry & Policy Execution (#10965, #10962): Telemetry SSL connections now verify server certificates, and columnstore policies reset search_path after every COMMIT.

Operational Note: Because 2.32.0 includes loader changes, a PostgreSQL server restart is required for the upgrade to take full effect.

Server room with high-density server racks and overhead cabling at a computer center
Production database and historian server infrastructure. Photo: Royal Institute of Technology (CC BY-SA 3.0).

3. Faster Continuous Aggregates & Critical Bugfixes

For teams relying on continuous aggregates for OEE rollups, shift summaries, or Grafana dashboards, 2.32.0 delivers both speed and correctness fixes:

  • Faster Continuous Aggregate Refreshes (#10864): Watermark updates now happen once per batch rather than repeatedly, reducing overhead on large refresh windows.
  • Variable-Bucket & Realtime Fixes (#10296, #10745, #10970): Fixes continuous aggregate refreshes skipping the last invalidated bucket on variable-sized (e.g., timezone-aware or monthly) buckets, and fixes ORDER BY pushdown on realtime continuous aggregates.
  • Concurrent UPDATE / DELETE Fix (#10902): Resolves a regression introduced in 2.28.1 where concurrent UPDATE or DELETE statements on a hypertable under READ COMMITTED could silently affect 0 rows after waiting on a row lock.
  • COPY FROM Error Handling (#10854, #10855): Bulk ingestion via COPY FROM now properly honors ON_ERROR ignore and enforces REJECT_LIMIT on PostgreSQL 18+.
  • Compression Stability (#10887, #10961): Fixes a repalloc error on certain batches over 992 rows and resolves race conditions between compress_chunk, decompress_chunk, and concurrent DDL.

Should You Upgrade?

Yes—especially if you are running TimescaleDB in production or managing multi-tenant/regulated industrial historians. Between the security hardening, the READ COMMITTED concurrent DML fix, and Adaptive Integer Compression enabled out of the box, TimescaleDB 2.32.0 is a worthwhile upgrade. Just remember to schedule a brief maintenance window for the required PostgreSQL restart and verify your backup before running ALTER EXTENSION timescaledb UPDATE.


Image Credits & Open Source Licensing:

  • Featured Header: Grafana time-series monitoring dashboard. Screenshot: Linux Screenshots (CC BY 2.0).
  • Server Infrastructure: Server racks and cabling at the KTH Parallel Computer Center. Photo: Royal Institute of Technology (CC BY-SA 3.0).

More from the blog