How Easee Consolidated Time-Series Operations Across 1M+ Chargers with Tiger Data

A Norwegian EV-charging company reduced storage costs and gained real-time operational visibility by migrating from a split Aurora/Redis stack to a single Tiger Cloud platform on AWS

Easee, a Norwegian maker of smart EV-charging hardware with nearly one million chargers deployed across Europe, ingests continuous telemetry from every device: 200 observation types per charger, arriving at one-second granularity. Before Tiger Data, Easee stored this time-series workload on AWS Aurora alongside a Redis cache for latest-value queries. The split architecture resulted in high costs and operational complexity. After migrating to Tiger Cloud on AWS in May 2024, Easee consolidated to a single platform, cutting storage footprint while reducing infrastructure management overhead.

About Easee

Easee designs and manufactures wall-mounted EV chargers that sense load conditions, adapt to available power, and report detailed operational telemetry back to a cloud platform. Each charger is essentially a sensor node. With close to one million units deployed, Easee operates a constellation of IoT devices that generate constant machine data.

Most EV-charging platforms treat chargers as discrete units. Easee treats them as a distributed sensor network. Every charger logs observations (operating mode, temperature, charge current, power factor, software version, error states) keyed by device serial number, observation type, and timestamp. Querying that data at scale requires a database built for both high-volume inserts and efficient historical queries. The questions are simple: How much did a customer charge last month? Did this charger overheat days ago? What's the peak load across a building right now?

Easee was founded in Norway and is now distributed across Europe, with engineering teams focused on hardware, firmware, and the cloud platform powering customer apps, partner integrations, and support operations.

The Challenge

Before Tiger Cloud, Easee ran AWS Aurora for transactional data and time-series observations, backed by Redis for caching the latest values from each charger. Redis handled roughly 100,000 requests per minute. This split stack created multiple problems:

• Storage was the dominant cost line item: Every observation from every charger accumulated on Aurora with no elegant way to compress or tier old data without fragmenting the query model.

• Ingestion performance was fragile: Workers batched observations and wrote to Aurora, but as device count grew, managing insert latency meant constant tuning of indexes, connection pooling, and write concurrency. The more chargers, the harder it got.

• Two systems meant two operational surfaces: Keeping Redis and Aurora in sync, managing failover for each, monitoring dual replication. That distracted from product development, was costly, and complex. 

• Storage bloat accelerated: Easee had accumulated roughly 50 terabytes of historical observations. As the charger fleet was projected to triple within two years, they faced a choice: pay for more Aurora and storage, or consolidate.

Why Tiger Data: An Architecture-first Decision

Easee evaluated TimescaleDB early after reading technical literature on time-series databases. The decision to move to Tiger Cloud was driven by operational pragmatism. They did not want to operate and scale a TimescaleDB cluster themselves.

The key decision criteria were:

• Single platform, not split: One database instead of two systems. One replication topology instead of two.

• Compression efficiency at scale: Tiger Cloud achieves over 90% storage reduction for time-series data, letting Easee keep more data hot while reducing bills.

• Operational reliability: A managed service meant no Postgres upgrades, backup pipelines, or failover orchestration. That work disappears.

• Data tiering to cost-optimize: Tiger Cloud moves old data to S3 Parquet at the 3-month mark, keeping hot data on performant storage.

• Fully-managed service: Easee evaluated building their own TimescaleDB cluster on EC2. The cost of engineering operational layers plus ongoing toil outweighed savings. Tiger Cloud aligned with Easee’s priorities: focus on the data model and query optimization, not Postgres cluster operations.

The Chronicle Stack

Easee calls their time-series service "Chronicle." Data flows from a charger to a customer-facing query in the following protocol: every charger emits observations at one-second intervals to an AWS Kinesis stream. Lambda workers consume the stream in batches (500-1000 messages per batch), validate devices, and write to Tiger Cloud using ON CONFLICT DO NOTHING, handling retries via SQS. Data is compressed within one day of arrival in Tiger Cloud, tuned down from an initial one-month window, achieving 50-90% compression ratios. Data older than three months tiers to S3 as Parquet files. Redis remains as a hot cache for the 100K requests/minute latest-value lookup pattern. Easee is evaluating whether shared buffer tuning in TimescaleDB might eventually replace it. Customer-facing APIs query Chronicle via a single historical-data endpoint parameterized on device serial number, observation ID, and time span. Support engineers can deep-dive into a charger's year-long history for diagnostics without query performance degrading.

Results: What They've Seen

• Significant cost reduction from storage consolidation and compression: By optimizing compression and tiering in TimescaleDB, Easee reduced their time-series storage footprint from 15.6 TB down to 8–10 TB, a savings of roughly 35–50% with no data loss. They achieved this by tuning a single parameter: the compress-after window. They started at one month, tested 22 days, then one day. Each step revealed that query traffic dropped off sharply beyond the threshold, so they kept lowering it. The result was hundreds of gigabytes shaved and substantial cost savings from a single setting change. Compression ratios now range from 50–90% depending on observation type. Power-draw observations compress more aggressively than sensor-state observations, an important distinction in data-intensive applications.

• Query performance and operational visibility: Easee targets 100-200 millisecond query latency for customer-facing historical lookups. On-charger diagnostics queries complete sub-second when querying hot data. Queries against tiered S3 Parquet data are slightly slower but deterministic. Consolidation improved operational visibility. Everything lives in one database now, which means real-time dashboards without ETL latency. Billing is accurate: customer reports showing kilowatt-hours charged query a single source of truth.

• Technical partnership and roadmap alignment: Easee credits Tiger Data with unlocking optimization wins. Continuous aggregates and materialized views are next, so customer dashboards do not re-compute historical sums repeatedly.

Value Beyond The Tech–how Tiger Cloud Brought Value To Essee’s Business:

• Cost reduction: Hundreds of gigabytes of storage eliminated through compression and tiering, reducing per-device operational costs as the fleet scales.

• Operational simplification: Single platform replaces dual databases, reducing infrastructure toil, support surface, and deployment complexity.

• Real-time visibility: Consolidated data enables accurate billing, fast diagnostics, and future real-time dashboards without ETL gaps.

• Scale without friction: Tripling the charger fleet with no architectural redesign. Just data growth on proven infrastructure.

Looking Ahead

Easee is targeting a threefold increase in deployed chargers over the next two years. On the old split stack, this meant Aurora provisioning increases and the burden of operating two systems at a larger scale. On Tiger Cloud, the data model does not change. It just gets bigger. The architectural decision compounds as Easee scales. One database, one replication topology, one set of compression parameters. No split path to reconcile as the fleet grows.