This is an installment of our “Community Member Spotlight” series, in which we invite our customers to share their work, spotlight their success, and inspire other users in the physical world with new ways to use Tiger Data to solve problems.

In this edition, Tristan Vermeesch, Software Engineer at Companion.energy, shares why his company migrated real-time sensor telemetry from Azure PostgreSQL to Tiger Cloud, unlocking improved query performance, faster ingest, lower storage costs, and a cleaner architecture for future growth.

---

About the Company & Team

Most energy infrastructure today operates in isolation. A grocery store has solar panels and a battery, but they're not optimized together. An office building has multiple power draw points: HVAC, EV charging stations, lighting, and more. Each one consumes energy independently. A telecom operator managing thousands of antennas pays fixed rates for peak demand even when the grid has cheap power available during off-peak hours.

Companion.energy solves this by gathering continuous data from our customers' infrastructure. We forecast demand and pricing using machine learning, then automatically optimize what can be controlled: charging or discharging batteries, enabling or disabling solar panels, shifting loads, and more. We built Companion.energy to handle data arriving every minute from hundreds of customers' distributed systems. We operate across Belgium and beyond, optimizing everything from large grocery chains to telecommunications infrastructure. We’re a small team, but very knowledgeable about energy infrastructure.

The Challenge

When we started, our entire platform ran on a single Azure PostgreSQL instance with flexible server options. It worked initially, but as data volumes grew—continuous sensor readings from more customers, longer historical records—performance degraded quickly. We tried adding more compute and memory, but the database simply couldn't keep up with the continuous inflow of data. Queries that had been fast became slow. Our customer-facing dashboards began to time out. Customers complained about page load times of two to three minutes.

We quickly discovered that our most frequently-used query (DISTINCT ON meter_uuid for pulling latest meter readings) would never finish on large customer accounts. It timed out consistently. We tried rewriting it, but the new version broke on small sites with only old data. The frontend's automatic 3x retry eventually finished the job. We put a 30-second statement timeout in place as a guard, but that was a band-aid. The proper fix required a database feature we didn't have: skip-scan optimizations on the hypertable physical order. Azure PostgreSQL's Apache 2 licensed TimescaleDB extension didn't include that.

Two months later, in October, Azure patched our production server. There was no advance notice and no way to prevent the outage. We went down 100% for 25 minutes with zero warning. Meanwhile, storage was becoming unsustainable. We were pricing out ways to move raw meter data out of the database just to keep it manageable. We'd written "avoid future database problems (size, performance)" as a line item in our roadmap.

The real problem was deeper. We'd hit a constraint that wasn't just about throwing hardware at it. We were running TimescaleDB on Azure Flexible Server, which gave us the extension but not the full product. We had no compression policies. We had no continuous aggregates. We couldn't access the features designed to solve exactly this problem.

Why Tiger Cloud: The Architecture-First Decision

We spent six months evaluating alternatives. My first instinct was MongoDB, which had just released time-series features. After thousands of engineering hours, we realized their time-series model didn't support the relational joins we needed for cost analytics. We abandoned it. Next we looked at InfluxDB and ClickHouse. Both are optimized for time-series and analytics, but both require significant learning curves. ClickHouse especially demands manual indexing and continuous tuning. That was overhead we couldn't afford as a small team. Neither offered meaningful improvements over what we already had.

We didn't need to migrate databases at all. We needed the full product version of TimescaleDB. We'd already bet on Postgres as a company. We knew it. Every engineer on our team could write SQL. We'd already been running TimescaleDB on Azure, so the question wasn't whether to use TimescaleDB—it was whether to get the full feature set.

Tiger Cloud changed the equation. It gave us the features Azure's Apache 2 edition held back: compression policies, continuous aggregates, and skip-scan. Ultimately, we made the decision to commit our entire platform to Tiger Cloud instead of trying to band-aid Azure.

The Stack: Real-Time Optimization Architecture

All our services connect through Tiger Cloud as the central source of truth. Continuous sensor data arrives from customer equipment and flows through our platform via message queues and pipelines. Multiple internal services consume this stream, processing and transforming data before writing results back to Tiger Cloud. We maintain separate Tiger Cloud instances for operational isolation—one for customer-facing features and one for market data analysis. This separation ensures that high-volume market data ingestion doesn't impact real-time customer features. All services run within a secure Azure V-Net with Tailscale for access control. We query Tiger Cloud via the CLI and MCP interface rather than direct database connections, which feels safer and makes it easier to audit what queries are running.

Results: From Skip-Scan Timeouts to Microseconds

1. 25x faster queries with skip-scan: Our best result is that meterdata latest/earliest lookups went from 4,950 milliseconds to 202 milliseconds. That's a 25x improvement. Here's what happened: on Azure, we were running queries to pull the latest reading for each monitoring point. The query was slow because it had to scan every chunk looking for the most recent value. When a customer had millions of data points, it timed out. When we tried rewriting it for performance, we broke the small customers with only old data. We needed skip-scan: a feature that uses the hypertable's physical ordering to jump directly to the chunk we need. Azure's Apache 2 edition didn't have it.

On Tiger Cloud, we leveraged TimescaleDB's native skip-scan functions, which use the hypertable's physical ordering to jump directly to the data we need. We also deleted workarounds that only existed to dodge statement timeouts. Those loops added latency and complexity for nothing. Just moving our database there, the performance improvements were immediate and dramatic.

2. 98% compression rate, turning 1.7 terabytes into 39 gigabytes: On Azure, we were continuously adding storage as data accumulated. Our largest data tables were growing unsustainably, together holding approximately 915 GB of raw data. We projected compress