How Kempower Achieves Sub-Second Query Performance and 93% Compression Across 20,000+ Charging Points with Tiger Data on AWS

Manufacturing leader in Electric Vehicle (EV) charging hardware reduced storage footprint 15x by migrating to Tiger Cloud on AWS.

Kempower is a Finland-based manufacturer with teams distributed across Europe, North America, and Asia-Pacific. The company designs and manufactures the physical EV chargers and embedded Linux firmware, while simultaneously operating the Charge I cloud platform that powers real-time visibility for its customers. Today Kempower operates 20,000+ active charging points globally. Kempower migrated Charge I's core telemetry system from Elasticsearch to Tiger Data, achieving 93% storage compression and enabling new capabilities for handling late-arriving data at scale. This case study outlines the team's evaluation process and the benefits they've seen running Tiger Cloud on AWS in production.

About the Company and Team

Charge point operators and fleet managers running buses, trucks, and heavy mining equipment lack real-time visibility into charger utilization, device health, and session diagnostics across dozens or hundreds of sites. Without this visibility, downtime in a fleet charging depot cascades immediately into vehicle downtime and revenue loss.

Kempower addresses this through Charge I, a cloud platform that ingests live telemetry from distributed EV charging hardware and surfaces that data to end users through a serverless, event-driven architecture running entirely on AWS. The platform processes continuous streams of session data (handshakes, power events, connection state changes) and device metrics (temperatures, currents, voltage profiles) from individual charger units, aggregates them across regional deployments, and delivers sub-second query response times to customer-facing dashboards and APIs.

The Challenge

For the first generation of Charge I, Kempower built the telemetry backbone on Elasticsearch. Elasticsearch was a pragmatic choice: the team had deep experience with the technology, it was widely available as a managed service, and it handled the initial scale without friction.

As the platform grew (more chargers deployed, more sensors per charger, longer data retention windows), the cost equation broke down. Elasticsearch charges by storage volume consumed, and storage volume compounds every month as the fleet grows and new types of device metrics get added to the pipeline. The cost per terabyte was predictable, but the total bill scaled linearly with growth. For a manufacturing business shipping tens of thousands of units per year across multiple regions, this linear cost model was unsustainable. As Juha Varkki, the lead architect at Kempower, noted: "The bill scales linearly and that's not something we're so fond of."

Beyond cost, Elasticsearch presented operational pain points specific to time-series workloads. Late-arriving data (common in IoT deployments where a charger may be offline and replay historical readings later) created issues with tiering and rollover logic that required manual intervention. Each month brought new operational friction that Elasticsearch was not designed to solve.

Kempower needed a solution that compressed time-series data intelligently, eliminated linear cost growth, handled late-arriving data as a first-class problem, and gave them a familiar SQL query layer for both real-time applications and analytical work. They wanted a managed service, not another self-hosted database to operate.

The Solution and Why Tiger Data

Kempower's evaluation was methodical. The team reviewed multiple platforms (InfluxDB, DynamoDB, and self-hosted TimescaleDB) with clear decision criteria: compression efficiency, cost predictability, operational simplicity, and SQL familiarity.

Tiger Cloud stood out for two technical reasons. First, Tiger Cloud's hypertable design and compression algorithms are purpose-built for high-cardinality, time-stamped data. The team ran a proof-of-concept with their production dataset and observed immediate results: 54 gigabytes of uncompressed development environment data compressed to 4 gigabytes (93% compression ratio). All three years of historical development data fit in system RAM. As one of Kempower's senior data engineers observed: "The compression and the downsampling has been really amazing...the documentation [that Tiger Data has] is really great."

Second, Tiger Cloud on AWS meant managed infrastructure without the operational overhead of patching, scaling, and upgrading a self-hosted cluster. The team evaluated the cost of running TimescaleDB on EC2 themselves and concluded that Tiger Cloud's pricing, when accounting for operational toil, was actually cheaper than self-hosting.

In production, Kempower has encountered edge cases specific to their architecture (late-arriving data, continuous aggregate refresh patterns under high cardinality) that would have required deep database expertise to debug and resolve. The Tiger Data support team provided rapid iteration and fixes, helping them reach production stability quickly.

The Charge I Stack

The telemetry path flows from physical chargers in the field through a managed cloud architecture into Tiger Cloud. Kempower's Charge I platform runs about 500 AWS Lambda functions orchestrated through EventBridge and SQS, so adding TimescaleDB was a natural fit: it integrates tightly with the event-driven model.

Charger units in the field (approximately 10,000 systems across Kempower's installed base) stream session data whenever a charging event begins and send device metrics (temperature, voltage, current) at regular intervals. These messages arrive at an SQS queue, where five concurrent Lambda workers pick them up, validate the device identity, apply any necessary unit conversions or calibration offsets, and write the measurements to Tiger Cloud. Peak ingestion during load testing exceeded 60,000 rows per second; sustained production ingestion runs around 20,000 rows per second, which Kempower's architects confirmed as sufficient for current and planned growth.

The data model inside Tiger Cloud (fully-managed TimescaleDB on AWS) is deliberately narrow: instead of storing 800 separate columns per device (one for each possible sensor type) or shoving a 40 kilobyte JSON blob into a text field, Kempower implemented a classic fact-dimension model. A single hypertable stores key-value pairs (timestamp, device_id, measure_key, value), where measure_key maps to a semantic definition (for example, 'temperature_c', 'power_draw_watts') in a dimension table. This design achieves two things: it keeps the fact table sparse (most cells never written, no need to store NULL), and it makes compression extremely effective because the hypertable has high cardinality on the key columns but repetition on the values. Continuous aggregates handle downsampling (rolling up the raw 1-minute data into 5-minute, 15-minute, and hourly summaries that drive the Charge I UI).

Kempower deployed Tiger Cloud across three AWS regions. Each region runs independently with a VPC-peered connection pool, allowing the Charge I platform to route queries to the nearest database and distribute the write load geographically. Charge I telemetry flows from distributed charger units through an SQS ingestion queue into Lambda workers, which validate and transform data before writing to Tiger Cloud across three AWS regions. Continuous aggregates materialize multi-scale summaries that power real-time dashboards.

Results: What Kempower Has Seen

• Shrinking the data footprint with storage compression: The 93% compression ratio observed in the proof-of-concept has held in production. Kempower's original charging-session dataset (raw historical data spanning years of deployments) compressed from an estimated 17 terabytes down to approximately 2 terabytes. Combined with a newer high-frequency device-metrics stream that adds roughly 1 terabyte per month of uncompressed data, Kempower's total active storage footprint of 35 terabytes would be orders of magnitude larger on an uncompressed platform.

• Growth without cost shocks: At current growth rates and retention windows, Tiger Cloud's pricing is predictable and decoupled from the number of devices or sensors in the field. The team pays per instance and storage, not per gigabyte ingested. A 2x growth in the installed base does not trigger a 2x increase in database cost (a fundamental shift from the Elasticsearch experience).

• Query performance and reliability: Kempower's customer-facing dashboards depend on sub-second query response times. A fleet manager opening Charge I needs to see current device status, session history, and historical trends with no perceptible delay. Tiger Cloud delivers on this requirement consistently.

• Operational simplicity: Tiger Cloud's managed offering eliminated the need to staff a dedicated database operations role. Kempower's team focuses on application features and data modeling; Tiger Data's team handles patching, backup, availability, and version upgrades. When bugs or edge cases surfaced during the first months of production (continuous aggregate refresh patterns under very high cardinality), the support team diagnosed and fixed them with minimal back-and-forth.

Looking Ahead

Kempower is targeting significant expansion in its installed base over the next two years (roughly seven times the current fleet size across existing and new markets). The company is also exploring new data streams: real-time power quality analytics, predictive maintenance signals derived from device metrics, and expanded regional coverage into markets where connectivity patterns differ from Europe and North America.

The architectural decision to run all telemetry on a single database grows in value as the fleet scales. There is no split architecture to maintain, no reconciliation logic as query patterns evolve, no second database strategy to second-guess. The data model does not change as the volume grows (it simply gets bigger). For a manufacturing company operating distributed hardware at global scale, that simplicity matters.