--- title: "How Companion.energy Reduced Query Latency 25x and Compressed Terabytes to Gigabytes with Tiger Cloud" published: 2026-08-31T15:04:26.000-04:00 updated: 2026-08-31T17:58:30.000-04:00 excerpt: "How Companion.energy optimized real-time energy data: 25x faster queries, 43.5x compression, continuous aggregates, and unified Tiger Cloud architecture." tags: Dev Q&A, Tiger Cloud authors: Tristan Vermeesch --- > **TimescaleDB is now Tiger Data.** _Migrating real-time sensor telemetry from Azure PostgreSQL to managed TimescaleDB, we unlocked skip-scan optimizations and compression that turned a scaling crisis into an architecture that handles petabytes._ ## 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. ![Companion.energy’s real-time energy optimization stack centers on Tiger Cloud as the source of truth. ](https://assets.tigerdata.com/blog/2026/08/energyplatform.svg) __Companion.energy’s real-time energy optimization stack centers on Tiger Cloud as the source of truth. Sensor data flows left to right through 30-40 microservices, with separate instances isolating market data from customer-facing operations.__ ## 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 compression would get us to about 92 GB. When we turned on the Hypercore columnstore on Tiger Cloud, those tables compressed to 28 GB. We beat our projection by 69%. The full picture across our largest compressed tables tells the real story: - **Table 1:** 1,084 GB logical to 22 GB physical (98.0% saved, 49.8x compression) - **Table 2:** 427 GB to 11 GB (37.2x) - **Table 3:** 197 GB to 6.2 GB (32.6x) - **Table 4:** 2.5 GB to 81 MB (31.5x) In total: 1.7 TB of logical data now sits in 39 GB of physical storage. That's a 43.5x ratio. Compression directly reduced our infrastructure costs and eliminated the monthly ritual of scaling up storage. It made it feasible to retain years of historical data for analytics and model training without the bill ballooning. When we enabled it on Tiger Cloud, it was like a surprise that the few terabytes of data were only like 300 gigabytes now. Which is a huge cost reduction. **3\. Leveraging Continuous Aggregates to materialize 283 million rows:** We routed our energy-cost dashboard reads through continuous aggregates that materialize pre-rolled hourly and daily data. Together, these aggregates materialize 283 million rows, replacing scans of the raw 807-million-row table. These aggregates couldn't exist on Azure. The compute and storage overhead would have been prohibitive. On Tiger Cloud, with compression and efficient hypertable storage, they're free. The dashboard is now snappier because we're reading pre-rolled data instead of raw measurements. **4\. Scanning billions of rows in seconds:** Right now in production, here's what we're seeing: - Counting 262.7 million rows across the last 30 days of sensor data takes 10.5 seconds. That's roughly 25 million rows per second against compressed chunks. - A 90-day range scan for a single sensor against our 4.64-billion-row sensordata hypertable takes 1.5 seconds. For contrast, here's where we started on Azure: a 6% buffer cache hit ratio, disk reads at 2.8 milliseconds per page against 0.01 milliseconds when cached. Queries were reading 1,515 pages to return only 17,072 rows because vacuum was blocked and the planner kept choosing the wrong index off stale statistics. 5\. **Managed observability and infrastructure reliability:** One of the biggest surprises during migration was the operational simplicity. Tiger Cloud provides managed observability for all our databases—logs, query metrics, and performance insights—that would have been painful to set up and maintain on Azure. We went from manually piecing together monitoring across tools to having a cohesive view of database health. One team member highlighted how valuable this is: _"We now have managed observability for all our databases, which was quite painful to maintain on Azure."_ Beyond that, the support experience has been exceptional. When we've had questions or feature requests, the responsiveness from the Tiger Data team has been outstanding. They understand our use case and move quickly to help or implement what we need. That level of partnership is rare and makes a real difference when you're running mission-critical infrastructure. **6\. Improving developer velocity to achieve forking in 5 minutes:** Before Tiger Cloud, testing new features against production-like data meant downloading terabytes to local machines. That was prohibitive in cost and time. Tiger Cloud's forking feature lets us spin up a fresh database with production data in minutes. Everyone on the team uses it now. It removed a major friction point in the development cycle. You just need to work on a feature, spin up a fork, wait five minutes, and you can just continue working. Everyone uses it here. **7\. Migrating in eight weeks, maintaining a steady replication at 50 MB:** We ran the migration using Tiger's LiveSync inside our own Kubernetes cluster, replicating from Azure PostgreSQL into Tiger Cloud across our table set. Evaluation took five months, while the migration itself took roughly eight weeks end-to-end. We validated our staging environment and achieved exact row-count parity on every table. INSERT, UPDATE, and DELETE all replicated in under a second, with typical lag of 15 to 90 milliseconds. Replication held steady at around 50 MB of lag the whole way through, so we were ingesting new data as fast as it arrived on the old database. The cutover was completed by one engineer in about 16 hours. The long pole surprised us: it wasn't data volume and it wasn't replication. What ate the night was converting one large table into a hypertable in place. The conversion timed out repeatedly through the GUI client, then through psql. What worked in the end: rename the table to a backup, create an empty hypertable in its place, then copy the data across. Once backfill finished, we flipped every connection string in one prepared change. GitOps apps then confirmed the migration was successful. Within days of cutover, the platform was noticeably snappier across the board. Our team noticed it immediately in dashboard responsiveness and query performance. Ultimately, replication held steady at 50 MB the whole way through—we were ingesting new data as fast as it arrived on the old database. ## Looking Ahead: Scale Without Rearchitecture We're targeting significant scale in the coming month. Larger customers are joining the platform, bringing 10x and 100x the data volumes. New product lines are in development that will add analytics and machine learning capabilities. Our pipeline now includes customers whose data requirements span from gigabytes to petabytes. The architectural decision to run everything on Tiger Cloud means we can scale without fundamental rearchitecture. We're not splitting between a time-series database and an OLAP warehouse. We're not managing separate hot and cold storage tiers. The same database handles real-time sensor ingestion, customer queries, analytics, and model training. As our dataset grows from terabytes to petabytes, the data model doesn't change. It just gets bigger. That's the compounding payoff of the skip-scan and compression wins. They're not just faster and cheaper today, but will continue to be tomorrow. They're architecture decisions that eliminate the rearchitecture work that comes later.