DEV Community: Nicole Ghalwash

TimescaleDB 2.28: Faster Queries, Lighter Operations, and Better Schema Evolution

Nicole Ghalwash — Wed, 29 Jul 2026 12:30:13 +0000

Time-series analytics at scale creates operational friction. When you're running continuous aggregates, columnar storage, and complex analytical patterns, each new metric, query pattern, and configuration tuning attempt adds complexity. Refreshes block each other, configuration changes require rebuilds, and new aggregates mean recomputing entire rollups.

Over recent TimescaleDB releases, we've prioritized minimizing these hurdles by leveraging bloom filters to bypass redundant processing during high-volume operations on columnar storage. We also expanded vectorized execution across more query patterns and simplified continuous aggregate workflows by combining refresh and compression.

Now with TimescaleDB 2.28, we're making common analytical queries faster without code changes, making continuous aggregate operations less disruptive and more flexible, and eliminating friction when evolving your schema and configuration. The result is faster queries, lighter operations, and the ability to evolve your analytics alongside your application as it scales.

TL;DR

Lighter, more flexible continuous aggregates:

ADD COLUMN on CAggs: Add new aggregations in place without rebuilding
Fine-grained locking: Refreshes no longer serialize unrelated operations
Incremental refresh batching: Break large refreshes into batches instead of one heavy operation
ANALYZE and VACUUM: Maintenance commands now work directly on continuous aggregates

Faster queries on compressed data:

Metadata-driven first() and last() queries: Answer from batch metadata without decompression
Vectorized CASE expressions: Conditional logic stays on the fast path
Batch Sorted Merge for more queries: Lighter-weight sorting on compressed data

Better operational flexibility:

Sparse index retrofitting: Update configuration on existing chunks without recompression
Compression settings clarity: Warnings prevent misconfiguration
GUC for bulk loads: Skip invalidation tracking during migrations
Nullable ORDER BY safety: Fallback to correct compression path

Also: PostgreSQL 15 support ends with 2.28. Plan your upgrade to PG16, PG17, or PG18.

Schema evolution: ADD COLUMN on CAggs

Schema evolution lets you add new aggregated columns without dropping and rebuilding. Before 2.28, adding a metric meant recreating the entire CAgg, recomputing all historical data (hours on large datasets), and breaking downstream consumers. Now you can ADD COLUMN with GENERATED ALWAYS AS and backfill incrementally.

-- Add a new metric to an existing CAgg
ALTER MATERIALIZED VIEW conditions_summary_hourly
  ADD COLUMN max_temp double precision
  GENERATED ALWAYS AS (
    max(temperature)
  ) STORED;

-- Backfill historical data
CALL refresh_continuous_aggregate(
  'conditions_summary_hourly',
  NULL,
  NULL,
  force => true
);

How we made continuous aggregates operational at scale

Real-time dashboards on operational data used to force a choice: refresh frequently and block bulk loads, or refresh less often and accept stale data. Every continuous aggregate refresh acquired a table-wide lock on its materialized hypertable, blocking concurrent operations. In 2.28, we switched to row-level locking on the continuous aggregate catalog entry. Only one refresh processes a CAgg's invalidation log at a time, but the materialized table is free for concurrent operations. Refreshes and bulk loads now run in parallel.

We also made continuous aggregates more flexible. ADD COLUMN on CAggs enables you to evolve your analytical schema in production by adding new aggregations as you learn what data you need, without downtime or rebuilds. Your dashboard design no longer locks you into upfront predictions.

-- Before 2.28: refresh acquired table-wide lock
-- After 2.28: refresh acquires only catalog row lock
CALL refresh_continuous_aggregate(
  'metrics_hourly',
  '2026-01-01',
  '2026-02-01'
);
-- Other refreshes, bulk loads, and DDL can proceed

2.28 also adds two capabilities that make continuous aggregates evolve with your application:

Incremental refresh batching processes large time windows in smaller batches instead of single long-running transactions. Before 2.28, refresh_continuous_aggregate() materialized the entire window atomically, holding resources and blocking vacuums. Large windows could take hours and fail mid-way. Now you can batch them.

   -- Refresh a 30-day window in smaller batches
   CALL refresh_continuous_aggregate(
     'metrics_hourly',
     now() - INTERVAL '30 days',
     now(),
     options => '{
       "buckets_per_batch": 10,
       "max_batches_per_execution": 20
     }'::jsonb
   );

Schema evolution lets you add new aggregated columns without dropping and rebuilding. Before 2.28, adding a metric meant recreating the entire CAgg, recomputing all historical data (hours on large datasets), and breaking downstream consumers. Now you can ADD COLUMN with GENERATED ALWAYS AS and backfill incrementally.

-- Add a new metric to an existing CAgg
ALTER MATERIALIZED VIEW conditions_summary_hourly
  ADD COLUMN max_temp double precision
  GENERATED ALWAYS AS (
    max(temperature)
  ) STORED;

-- Backfill historical data
CALL refresh_continuous_aggregate(
  'conditions_summary_hourly',
  NULL,
  NULL,
  force => true
);

ANALYZE and VACUUM now work on continuous aggregates directly. Maintenance commands automatically maintain accurate planner statistics across the materialized hypertable and all its chunks, ensuring query plans stay optimal.

Faster queries on compressed data

One of the most common queries in time-series workloads is "give me the latest value per series." Dashboards and monitoring systems run it constantly. It's a simple pattern: find the first or last value in a time range. But on compressed data, answering that query used to require decompressing entire batches just to find values that are already in the metadata. Time-sorted batches store first and last values as metadata. But before 2.28, the database decompressed anyway to answer those queries.

In 2.28, TimescaleDB extracts first(value, time) and last(value, time) aggregates directly from batch sparse indexes. No decompression. For "latest reading" queries that consume significant resources at scale, that means meaningful speedup with zero query changes. Here's what that looks like:

-- Define firstlast sparse index
ALTER TABLE metrics SET (
  tsdb.index = 'firstlast(temperature)'
);

-- Note: Use rebuild_sparse_index() to retrofit existing chunks
-- New chunks now answer this query from metadata alone
SELECT
  device_id,
  last(temperature, time)
FROM metrics
WHERE time > now() - INTERVAL '7 days'
GROUP BY device_id;

Beyond first/last, we also extended vectorized execution to cover CASE expressions. Before 2.28, conditional logic in aggregations forced columnar queries to fall back to row-by-row processing, making identical queries perform very differently depending on whether a CASE expression was present.

-- This query now stays fully vectorized
SELECT
  time_bucket('1 hour', ts) AS bucket,
  SUM(
    CASE WHEN status_code >= 500 THEN 1 ELSE 0 END
  ) AS error_count,
  AVG(
    CASE WHEN latency_ms > 1000 THEN latency_ms END
  ) AS slow_avg_latency
FROM requests
WHERE ts > now() - INTERVAL '7 days'
GROUP BY bucket;

Pivot-style queries, error rate calculations, and conditional metrics all stay on the fast vectorized path. For workloads that use conditional aggregations on compressed history, that eliminates the surprise performance cliffs.

Finally, Batch Sorted Merge now applies to more query patterns. ORDER BY queries on unordered compressed chunks without segmentation no longer fall back to expensive external sorts. The planner now replaces those sorts with lightweight metadata merges over pre-sorted batches.

Better operational flexibility and efficiency

Tuning time-series workloads means iterating on compression strategy. But historically, every configuration change (adding a sparse index, adjusting segmentby, optimizing orderby) only applied to future compressions. Existing chunks kept their old settings, creating inconsistent performance and confusion about why newly tuned queries behaved differently.

2.28 eliminates that friction. rebuild_sparse_index lets you retrofit sparse index configuration to existing chunks without recompressing. Sparse indexes are metadata. Updating them shouldn't require rewriting data. Below is the actual code snippet you can leverage:

-- Change sparse index settings on the hypertable
ALTER TABLE metrics SET (
  tsdb.index = 'minmax(value)'
);

-- Retrofit existing chunks without recompression
SELECT _timescaledb_functions.rebuild_sparse_index(
  '_timescaledb_internal._hyper_1_42_chunk'
);

Compression settings changes now emit warnings clarifying that new settings apply only to future compressions. This closes the gap: users assume ALTER TABLE sets configuration across the entire dataset, but it only affects new chunks.

For correctness, nullable ORDER BY columns now safely fall back to decompress-compress during recompression, preventing silent incorrect results when min/max metadata doesn't account for NULLs.

Gapfill row count estimation improved so time_bucket_gapfill queries get more accurate planner statistics and better query plans.

For bulk migrations, a new GUC timescaledb.skip_cagg_invalidation suppresses continuous aggregate invalidation tracking during bulk loads. Migration tools no longer generate useless invalidation entries that trigger expensive refresh storms.

PostgreSQL 15: Final Release and Migration Path

PostgreSQL 15 support ends with TimescaleDB 2.28. Going forward, only PostgreSQL 16, 17, and 18 are supported.

If you're on PG15, plan your upgrade to PG17 or PG18 now. We'll begin upgrading instances in production the week of September 15th, so you should plan your migration path over the next two months to avoid downtime. Postgres upgrades are typically non-disruptive (seconds to minutes of downtime using logical replication or physical backup/restore), and newer Postgres versions bring improvements in query parallelism, vector search optimization, and compression.

Upgrade to 2.28 today

For workloads running continuous aggregates at scale, columnar queries with conditional logic, or iterating on compression configuration, 2.28 removes operational friction: refreshes don't serialize, queries stay vectorized, and tuning doesn't require rewrites.

2.28 is available now. To learn more, check out the full release notes for a complete list of improvements, or try Tiger Cloud for free and experience TimescaleDB 2.28 on your largest hypertables. We welcome your feedback on GitHub. Please note that for Tiger Cloud customers, all improvements are live immediately. For self-hosted deployments, download the latest release and follow the upgrade guide.

What's New in Tiger Cloud: Bigger Performance Gains, Wider Platform Reach, Better Visibility

Nicole Ghalwash — Fri, 17 Jul 2026 18:51:12 +0000

This year, we've focused on improving three areas that define the Tiger Cloud experience:

Scale without splitting your architecture: Compression becomes a performance advantage. UPDATE and DELETE on compressed data run up to 160x faster, summary queries up to 70x faster. Storage scales to 80,000 IOPS and 64 TB on demand.
Spend less time configuring, more time shipping: Tiger Console auto-tunes hypertables, the PostgreSQL Source Connector moves data to Tiger Cloud without custom pipelines, and pg_textsearch brings production-ready BM25 search natively in Postgres.
Production-grade reliability, without the DIY tax: Tiger Cloud handles data residency, network isolation, disaster recovery, and visibility so you don't have to.

This past quarter we shipped deeper query engine optimizations in TimescaleDB, new regions, new enterprise networking options, and a long list of smaller improvements to how Tiger Console works day-to-day. Instead of listing every Tiger Cloud release on its own, here's what it adds up to, and why it matters: you can stay on Postgres as you scale, you'll spend less time configuring and more time shipping, and you get the reliability and visibility that time-series workloads actually need.

Scale without splitting your architecture

The moment analytical queries start competing with transactional ones, teams feel pressure to bolt on a separate analytical database. This quarter's TimescaleDB releases and storage upgrades ensure Postgres keeps scaling for time-series and analytical workloads instead of becoming the reason you re-architect. Here's what shipped, and why it matters.

Run queries and writes directly on compressed data, without the performance tax

Compression used to mean a trade-off: a smaller footprint for slower access. With the release of TimescaleDB v2.26, that trade-off keeps shrinking. Aggregate queries like COUNT, MIN, MAX, and FIRST/LAST now read straight from compressed metadata instead of decompressing full batches, up to 70x faster. Grouping with time_bucket() runs roughly 3.5x faster. Multi-column filters push down directly into compressed scans, cutting unnecessary decompression by half or more.

Writes get the same treatment. TimescaleDB v2.27 lets UPDATE, DELETE, and UPSERT on compressed chunks skip decompressing data that can't match, so selective write operations run up to 160x faster. Query rewriting can automatically route matching aggregations to a continuous aggregate, and continuous aggregate refreshes can compress chunks as part of the same job instead of needing a separate policy.

Continuous aggregates are now more reliable at scale. We fixed three stability issues that were constraining them: a memory leak, query correctness edge cases, and a deadlock during concurrent refreshes. As a result, you can now push continuous aggregates harder without operational workarounds or special handling.

Add full-text search without adding a search engine

As part of the pg_textsearch v1.0.0 release, BM25 full-text search now runs natively inside Postgres, and is production-ready. Add relevance-ranked search to your application without standing up and syncing a separate Elasticsearch cluster. In benchmarks at 138 million documents, pg_textsearch ran up to 6.5x faster than ParadeDB on typical multi-word queries and sustained 8.7x higher concurrent throughput. It ships with an <@> query syntax, a bm25_force_merge() function for segment consolidation, and support for Postgres 17 and 18. One less system in your stack to operate and keep in sync.

Scale storage on demand instead of provisioning for a peak that may not come

Scale plan services can now choose between 16,000 and 40,000 IOPS with up to 1,500 MB/s of throughput. Enterprise plans go up to 80,000 IOPS and 2,000 MB/s, with total capacity up to 64 TB. Changes apply without downtime, and you pay only for the IOPS you use. Size up as your workload grows instead of guessing at peak load today.

Spend less time configuring, more time shipping

None of the above matters much if half your week still goes to console configuration instead of building. The following updates hand more of that time back to you so you can focus on what matters: building your product, not configuring your database.

Build hypertables in a few clicks, without writing SQL

Define hypertable columns directly in Tiger Console instead of writing SQL. Configure a columnstore in the same step. For the best performance, you can enableautomated chunk tuning afterward, so you won't have to manually set chunk intervals.

Move data from Postgres into Tiger Cloud without building your own pipeline

The PostgreSQL Source Connector is now stable and ready for production use. Replicate an existing Postgres database into Tiger Cloud without hand-rolling a migration or sync pipeline. It supports a configurable worker count for the initial data copy, table selection by publication or direct selection, SSH tunneling, and bulk updates for table and schema mappings. Everything you need to bring production data over reliably.

Production-grade reliability, without the DIY tax

Data residency, network isolation, disaster recovery, and visibility into what's happening inside your database are table stakes for any fully-managed platform. The whole point of choosing Tiger Cloud is that you shouldn't have to design, build, and maintain that infrastructure yourself. Here's what shipped this quarter that takes more of that off your plate.

Meet data residency requirements in more places

Tiger Cloud is now available in two additional Azure regions: Germany West Central (Frankfurt) and Southeast Asia (Singapore). Teams with GDPR-sensitive workloads can now keep EU data in-region, and Asia-Pacific teams get local data residency and lower latency, without moving off Azure. For a list of all available regions, click here.

Keep database traffic off the public internet

Private endpoint support is now generally available across every supported AWS and Azure region. AWS PrivateLink connects from your VPC over the AWS private network. Azure Private Link does the same from your VNet over Microsoft's private backbone. Both are configured directly in Tiger Console and included on Scale and Enterprise plans, so database traffic never has to touch the public internet.

Recover easily when a region goes down

Cross-region backup already copies your data to a geographically distant region. Now Enterprise customers can restore directly from that backup in Tiger Console, closing the loop so a regional outage doesn't mean opening a support ticket to get your data back. To learn more, click here.

Catch problems in the tools you already use, before they escalate

Visibility should be simple. You shouldn't have to wait for a problem to surface before you can see it coming. The Tiger Cloud status page now lives at status.tigerdata.com, tied directly into incident response, so you can subscribe and get notified the moment an incident is created, updated, or resolved instead of finding out from a support thread.

Inside the Metrics tab in Tiger Console, a new Queries per Second graph gives a real-time view of throughput, making it easier to spot spikes or drops in query volume.

In the Insights tab, the query deep dive page now tracks CPU, memory, and storage IO (read and write) over time, so you can catch a query's resource footprint trending the wrong way and see its downstream impact on system health before it turns into a bigger problem.

Additionally, you can check the Chunk timeline in the Explorer tab to see how your data is organized across chunks. You can inspect sizes, time ranges, and whether each chunk is in the rowstore or columnstore. This lets you spot organization issues and monitor columnstore job health without running system queries.

Lastly, if you already monitor infrastructure elsewhere, Tiger Cloud now exports telemetry to Azure Monitor, plus PostgreSQL-specific metrics (replication, cache usage, background activity) to Amazon CloudWatch, Datadog, and Prometheus, with system-level disk IO and throughput metrics exported by default. Wherever you already look for problems, Tiger Cloud's data is there too. For a full list of available metrics you can export with Tiger Cloud exporters, click here.

Try Tiger Cloud for free

All of these features are live on Tiger Cloud. If you're already a customer, sign in and check out the latest TimescaleDB releases on your compressed hypertables and the new IOPS options if you're storage-bound.

If you're new to Tiger Cloud, start a free trial and see what a Postgres-native operational analytics database looks like.