--- title: "From 4 Databases to 1: How Plexigrid Replaced InfluxDB and Got 350x Faster Queries with Tiger Data" published: 2026-03-10T15:42:42.000-04:00 updated: 2026-03-24T13:29:49.000-04:00 excerpt: "Learn how Plexigrid provides real-time electrical grid visibility for distribution system operators by combining 4 databases into 1 database solution with TimescaleDB." tags: Dev Q&A, Tiger Data authors: Nicole Bahr --- > **TimescaleDB is now Tiger Data.** _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 others with new ways to use technology to solve problems._ _In this edition, Enrique Riesgo, Chief Software Engineer at Plexigrid, an electrical grid optimization software company, explains how Plexigrid optimizes grid network utilization with TimescaleDB._ Distribution System Operators (DSOs) have a blind spot: limited visibility into low voltage grids, typically under 20,000 Volts. For decades, distribution networks were designed around a simple one-way model with power flowing from centralized power generation to end consumers, so high-level monitoring proved adequate.  That model is breaking down. Demand is rising and getting spikier with increasingly decentralized power delivery. EV charging, batteries, heat pumps and other high-draw appliances can swing local demand fast, and solar can push energy back onto the grid. To operate reliably under these bi-directional flows, DSOs need much more granular, near-real-time visibility into what’s happening at the feeder/transformer/neighborhood level. Without that visibility, many DSOs fall back on blunt solutions like overbuilding infrastructure. They add capacity buffers of 100% or more to ensure the grid stays stable under worst-case scenarios. It works, but it’s expensive, slow, and resource-intensive, and those costs ultimately get passed through to consumers and producers. ## Optimizing Low-Voltage Grid Capacity with Plexigrid There’s a better approach than overbuilding. At Plexigrid, we build grid management software for the low-voltage network. The goal is straightforward: help DSOs operate closer to the true capacity of what they already have by giving them near real-time observability into load, voltage, and constraint violations across the distribution grid. We work with utilities in North America and Europe. When a feeder/transformer area starts approaching operational limits, Plexigrid reveals what’s happening in real-time, identifying local flexible loads that can be shifted to relieve the constraint, such as rescheduling EV charging windows, modulating heat pumps / HVAC setpoints, or accommodating incoming electricity from rooftop solar panels.  By aggregating sensor and endpoint data, we can compute the right combination of grid optimization to resolve constraints quickly and at the lowest cost. The outcome for DSOs is higher utilization of existing infrastructure and a meaningful delay in expensive upgrades like new cables, transformers, and other CapEx-heavy projects. Centralizing grid activity across households and producers also enables accurate digital twin development, software representations of physical grid assets and their behavior. With a digital twin, DSOs can move from reactive operations to informed predictive maintenance, sophisticated ‘what if?’ scenario planning, and evaluating the impact of new charging deployments or storage rollouts.  Delivering these insights requires a modern IIoT-style utilities architecture. Edge data collection from grid endpoints provides the raw sensor data required for informed analytics. Low-latency ingestion and aggregation ensure DSOs can quickly see state changes for real-time analytics and decisioning to manage capacity and resolve constraints before they become outages or violations.  ![Plexigrid architecture](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/03/plexigrid-architecture-diagram.png) ## Maturing the Grid Infrastructure Design In the initial Plexigrid POC, we optimized for speed and used four databases, each for a different slice of the system: - InfluxDB for [time-series telemetry](https://www.tigerdata.com/learn/time-series-database-what-it-is-how-it-works-and-when-you-need-one) (sensors, customer events) - TigerGraph for grid topology - MySQL and PostgreSQL for relational/analytical workloads That stack got us to a working POC, but it didn’t scale operationally. Running and integrating four databases across every new DSO deployment quickly became expensive and brittle. The biggest constraint was InfluxDB ingestion at scale. For customers pushing millions of datapoints, resource needs (memory/CPU) were hard to predict. When sizing was off, ingestion failed completely. We also hit storage limits that would stall ingestion entirely, leaving DSOs without up-to-date visibility when they needed it most. To keep the system functional, we ended up absorbing high InfluxDB licensing costs. At that point, the path was clear: if Plexigrid was going to scale to more DSOs, we had to remove the ingestion bottlenecks and simplify the architecture, moving from four databases down to one to reduce cost, complexity, and operational risk. ![Plexigrid data pipeline](https://storage.ghost.io/c/6b/cb/6bcb39cf-9421-4bd1-9c9d-fa7b6755ba0e/content/images/2026/03/plexigrid-case-study-diagram.png) ## Transitioning from InfluxDB to TimescaleDB When we looked for a replacement, we had a clear checklist: predictable performance at high ingest rates, consistent scaling across customers and data types, and support for both operational queries and analytics. We landed on TimescaleDB from Tiger Data because it’s built for high-ingest, high-read sensor workloads on PostgreSQL. Over the past 2 years, we consolidated our four-database POC stack into a single PostgreSQL/TimescaleDB system, and saw immediate improvements in ingest reliability and query performance. That consolidation also simplified how we ship our SaaS product. The application is fully containerized (Docker) and deployed in the form factor each utility requires: shared SaaS, dedicated SaaS, or on-prem binaries for regulated environments. The app writes telemetry and operational data to PostgreSQL/TimescaleDB, and we use object storage for file/blob data. Compared to InfluxDB, our teams found that implementing TimescaleDB had a shorter learning curve and delivered better ingest and query performance with the same engineering effort. Just as importantly, using a unified PostgreSQL/TimescaleDB architecture reduced maintenance overhead and gave us consistent deployment options, from cloud to on-prem, without changing the core data layer. > Using a unified PostgreSQL/TimescaleDB architecture reduced maintenance overhead and gave us consistent deployment options. - _Enrique Riesgo, Chief Software Engineer at Plexigrid_ ## Performance Improvements  The immediate win was ingest stability and predictability. When onboarding a new DSO, we often need to bulk-import historical measurements from existing systems. With InfluxDB, it was hard to size memory for that ingest. If we underestimated, ingestion failed. At massive sensor scale, InfluxDB routinely ran out of memory. For the same dataset, InfluxDB needed ~8 GB of RAM, while TimescaleDB stayed stable at ~300 MB. In practice, our ingest failures disappeared with TimescaleDB. We also saw major storage improvements. Importing large datasets in InfluxDB frequently hit storage limits and stalled ingestion. With TimescaleDB, specifically their hybrid row/columnar store, we reduced storage from ~350 GB to ~3 GB while keeping the data queryable for real-time analytics. Finally, query performance improved substantially, which matters for real-time grid operations. In Hypercore testing we saw ~90–95% lower query latency for key analytical workloads.  - 44% faster ingest - 95% storage reduction (350 GB → 3 GB) with columnstore - 90–95% reduction in query time for key analytical workloads - 350× speedup in query speeds (5 minutes → 0.5 seconds) > Hypercore has been a big win for us—excellent performance. - _Enrique Riesgo, Chief Software Engineer at Plexigrid_ For Plexigrid, standardizing on TimescaleDB at scale delivered faster, more reliable insights to DSOs. This improved grid stability, reduced costly overbuild, and enabled higher renewable penetration without rebuilding the distribution grid from scratch.