What We Heard: Three Patterns from Spring 2026 Events

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 we have 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 we have 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 we 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 we have 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 us next

The calendar doesn't really do summer breaks. If you want to keep the conversation going, here's where we'll be through the end of the year:

• Online Workshop: From MQTT to Dashboard: Real-Time IIoT Pipelines with Tiger Cloud, July 22.
• IMTS, Chicago, September 14-19.
• Ignition Community Conference, Sacramento, September 22-24.
• ISA Automation Summit & Expo, Florida, September 27-29.
• Enlit Europe, Vienna, November 10-12.

More events coming

We're still locking in the rest of the year. Keep an eye out on our events page, or subscribe to the newsletter if you'd rather have updates come to you.

Want to connect at an event not on this list? Reach out.

If we are not coming to your city, the Tiger Cloud trial is open whenever you are.