--- title: "What's New in Tiger Cloud: Bigger Performance Gains, Wider Platform Reach, Better Visibility" published: 2026-07-17T14:51:12.000-04:00 updated: 2026-07-17T14:51:12.000-04:00 excerpt: "Tiger Cloud ships up to 160x faster writes, native BM25 search, more storage, new regions, and better visibility on Postgres." tags: Tiger Cloud, Tiger Data authors: Nicole Ghalwash --- > **TimescaleDB is now Tiger Data.** 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](https://www.tigerdata.com/docs/integrate/connectors/source/sync-from-postgres) 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](https://www.tigerdata.com/docs/build/how-to/basic-compression) used to mean a trade-off: a smaller footprint for slower access. With the release of [TimescaleDB v2.26](https://github.com/timescale/timescaledb/releases/tag/2.26.0), 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](https://github.com/timescale/timescaledb/releases/tag/2.27.0) 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](https://www.tigerdata.com/docs/learn/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](https://github.com/timescale/pg_textsearch/releases#release-v1.0.0) release, [BM25 full-text search](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/tiger-cloud-extensions/pg-textsearch) 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.](https://www.tigerdata.com/docs/build/data-management/storage/manage-storage#high-performance-storage-tier) ## 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 enable [automated chunk tuning](https://www.tigerdata.com/docs/build/performance-optimization/improve-hypertable-performance#automated-tuning) afterward, so you won't have to manually set chunk intervals. ![Build hypertables in a few clicks, without writing SQL](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/07/create_hypertable.png) ### Move data from Postgres into Tiger Cloud without building your own pipeline The [PostgreSQL Source Connector](https://www.tigerdata.com/docs/integrate/connectors/source/sync-from-postgres) 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](https://www.tigerdata.com/docs/learn/tiger-cloud/regions). ### Keep database traffic off the public internet Private endpoint support is now generally available across every supported AWS and Azure region. [AWS PrivateLink](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/security/aws-privatelink) connects from your VPC over the AWS private network. [Azure Private Link](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-azure/security/azure-privatelink) 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.](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/service-management/fork-services#pitr-forks) ### 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](https://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_](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/monitoring#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. ![Inside the Metrics tab in Tiger Console, a new Queries per Second graph gives a real-time view of throughput](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/07/qps.png) In the [_Insights_](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/monitoring#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. ![In the Insights tab, the query deep dive page now tracks CPU, memory, and storage IO (read and write) over time](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/07/drill-down.png) Additionally, you can check the Chunk timeline in the [_Explorer_](https://www.tigerdata.com/docs/deploy/tiger-cloud/tiger-cloud-aws/service-management/service-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](https://www.tigerdata.com/docs/learn/columnar-storage/understand-hypercore). This lets you spot organization issues and monitor columnstore job health without running system queries. ![check the Chunk timeline in the Explorer tab to see how your data is organized across chunks](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/07/chunks_timeline.png) Lastly, if you already monitor infrastructure elsewhere, Tiger Cloud now exports telemetry to [Azure Monitor](https://www.tigerdata.com/docs/integrate/observability-alerting/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](https://www.tigerdata.com/docs/integrate/observability-alerting/exported-metrics). ## Try Tiger Cloud for free All of these features are live on Tiger Cloud. If you're already a customer, [sign in](https://console.cloud.timescale.com/login) 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](https://console.cloud.timescale.com/signup) and see what a Postgres-native operational analytics database looks like.