Senior Platform Engineer

What's new in Tiger Cloud: bigger performance gains, wider platform reach, better visibility. July 17th, 2026 This year, Tigerdata has 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 Tigerdata 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. Tigerdata 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 enable automated 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. 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. 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. 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.

What Tigerdata heard: three patterns from Spring 2026 events. July 1st, 2026 Spring 2026 was relentless. Tiger Data teams covered ten events across Europe and the US: GrafanaCON in Barcelona, Hannover Messe and AWS Summit Hamburg in Germany, AWS Summit London, ETHDenver in Colorado, the Offshore Technology Conference in Houston, Data Driven Oil & Gas in Texas, Sensors Converge and IOT Tech Expo in the Bay Area, and AWS Summit Los Angeles. Hundreds of conversations with platform engineers, SREs, industrial automation teams, oil and gas operators, blockchain infrastructure builders, and sensor hardware teams. That's a lot of badge scans. Three patterns kept showing up across every audience, and they're really different angles on the same shift: the market has moved past category education and into implementation-level scrutiny. Here's what that looked like on the ground. Pattern 1: Postgres is becoming the default for industrial and operational telemetry. Five years ago, telemetry workloads at scale defaulted to purpose-built time-series databases. InfluxDB. Prometheus. Specialized vertical stacks. The conversation at the booth has changed. At Hannover Messe, the world's largest industrial trade show, the most common question from automation and manufacturing teams was some variant of: "we have tens of thousands of sensors writing constantly, our current system is buckling, what do you do differently." Not "should we use a time-series database." Not "what is TimescaleDB." Those teams had already chosen Postgres before they walked up. They wanted to know if Tiger Data could keep them on it at the volumes they were already running. At Sensors Converge, the audience skews closer to the hardware end of the IIoT pipeline: sensor manufacturers, embedded systems engineers, and the people writing firmware for the devices feeding everyone else's databases. The questions were specific. How does storage behave when you're sampling at 100 Hz across 50,000 endpoints. What happens when a fleet of devices comes back online after a network outage and dumps a backlog. Workload questions, not category questions. At the Offshore Technology Conference in Houston, the energy sector followed the same shape. SCADA telemetry. Well monitoring. Equipment digital twins. Lifecycle analytics on multi-decade asset histories. Teams that already had Postgres in production wanted to know how far they could push it before having to reach for another system. The answer, increasingly, is further than they had assumed. The pull toward Postgres in these markets is consistent. Existing Postgres in production. Existing SQL skills on the team. No appetite for a second on-call rotation. Industrial software is conservative for good reasons, and the system that already runs the business is a much better starting point than a green-field rewrite. Customers like Mechademy, Flogistix, and Axpo are public references for what this looks like in production. Pattern 2: Split-architecture fatigue is becoming an explicit conversation. The second pattern builds directly on the first. Teams who split their architecture into "Postgres for transactions, ClickHouse or a warehouse for analytics" are increasingly explicit about regretting it, something Tigerdata has been arguing internally for years and are now hearing back from the field. At AWS Summit London, the booth was dense with platform engineers running on RDS or Aurora and feeling the analytical wall closing in. The question was usually some version of: "we are about to add a separate analytics database. Is there a path that does not require us to do that." A few years ago, the answer most teams accepted was no. They added the second system, built the pipeline, accepted the lag, and moved on. The conversation now starts from a different premise. Teams have either watched a peer team go through the split and pay the operational tax, or they have done it themselves and want out. At Hannover and OTC, the same pattern appeared on a longer timeline. Industrial teams that built their architectures a decade ago, with operational data in one place and analytics in another, are increasingly looking at consolidation. Multi-system data plumbing is one of the largest hidden line items in their engineering budget. The pitch that operational analytics can stay on the source of truth, with no pipeline, no drift, no second backup strategy, is landing differently than it did even two years ago. Speedcast's story is the cleanest public version of the before-and-after. They stitched together Kafka, Flink, and custom code to stream data from Postgres to Iceberg, and Tiger Lake replaced all of it. As Kevin Otten, their Director of Technical Architecture, put it: "It's the architecture we wish we had from day one." Pattern 3: The questions have gotten harder, and that's the clearest evidence of the first two. Across all ten events, the conversations got deeper than at any event series Tigerdata has run. The questions skipped the basics, and that alone says something: teams don't ask about compression ratios and failure modes when they're still deciding on a category. They ask once they've already made the decisions in Patterns 1 and 2, and they're just checking the implementation. At GrafanaCON, booth visitors asked about continuous aggregates, compression ratios, and how Hypercore behaves under high-cardinality dashboards. These are the questions teams ask when they are comparing implementations. The Grafana community is one of the most technically opinionated audiences Tigerdata talk to, and the depth of the questions has been climbing event over event. At Sensors Converge, the questions ran the same way at the hardware level. Specific sample rates. Specific endpoint counts. Specific failure modes. Nobody wanted a feature tour. They wanted to know whether the system would behave the way they expected under their workload. The share of conversations that started with "what is a time-series database" or "what is TimescaleDB" was lower than at any event series Tigerdata has run. The market has moved past category education. People know what they need, and they are picking implementations. That's the throughline across all three patterns: teams have already decided Postgres can carry this weight, they're done paying the split-architecture tax, and now they're evaluating implementations instead of categories. That's a good problem for a database company to have. Where you'll find Tigerdata next. The calendar doesn't really do summer breaks. If you want to keep the conversation going, here's where Tigerdata'll be through the end of the year: More events coming Want to connect at an event not on this list? Reach out. If Tigerdata is not coming to your city, the Tiger Cloud trial is open whenever you are.