Home Alternatives Time-series basics Data Center & Infrastructure Telemetry Postgres basics Postgres guides Postgres best practices

EV Charging Load Management

By Tiger Data Team

Updated at Aug 25, 2026

This article is for CPO (charge point operator) engineers and architects building or evaluating a load-management backend, not for a homeowner deciding which home charger to buy.

Tiger Data sells a database and has a point of view on how load-management data should be stored and queried. The goal here is a neutral, engineering-first look at the problem, including where a simpler setup is the right call.

EV charging load management is the practice of dynamically or statically limiting and allocating available electrical capacity across a set of chargers so total draw stays within a site's (or network's) capacity limit. Static (local) load management applies fixed per-charger caps with no live feedback loop; dynamic load management continuously adjusts those caps based on live meter and session data. Either way, the decision logic is only as good as the meter, status, and session data feeding it, which makes load management a data problem before it's a hardware one. This article covers that data architecture: the backend behind smart charging, load balancing, and OCPP-based (Open Charge Point Protocol-based) dynamic load management.

Why load management depends on OCPP data

Load management logic runs on three OCPP message types: MeterValues (live meter readings from each connector), StatusNotification (charger and connector state changes), and SetChargingProfile (the command that enforces a calculated load limit on a charger).

That distinction matters because OCPP itself doesn't make load-balancing decisions. It's the communication protocol between chargers and the central system: it carries meter and status data up and accepts charging-profile commands down. The decision of what profile to set, and for whom, lives in the CSMS (charge point management system) backend, the software layer at the center of any EV charging management system. OCPP 2.0.1 added native smart-charging-profile support and more granular per-session and per-device control than 1.6; the full comparison is in the table below.

What data load management actually needs

Four data inputs feed load-management logic:

High-frequency meter readings, at whatever interval the chargers report (often 15 seconds to a few minutes per connector)
Charger and connector status
Active session state
Site-level (or network-level) capacity limits

For the underlying schema for these four OCPP data types, see Tiger Data's guide to EV charging database architecture; this article picks up where that guide leaves off. The same high-frequency ingestion pattern applies to fleet telemetry, covered in Tiger Data's fleet telemetry database architecture guide, relevant for CPOs that also operate EV fleets.

The volume problem compounds quickly. One charger reporting meter values every 30 seconds is trivial; a site with a few dozen chargers, each with its own connector-level readings, status transitions, and active sessions, turns into a stream that must be read in aggregate and in real time on every relevant change, turning load management from a lookup into a genuine time-series data problem.

Where naive approaches break down at scale

A common early-stage pattern: log meter and status data to CSV or flat files and reconcile later. This works fine for a handful of chargers at a single site, but breaks down once volume scales past that: there's no efficient way to ask "what's the current aggregate load across all active sessions right now" from flat files, and that's exactly the question dynamic load management needs answered in real time, not after the fact.

Data quality is a less obvious, and documented, failure mode. A GitHub issue on a widely used open-source OCPP library shows chargers that don't respect MeterValuesSampledDataMaxLength on OCPP 1.6, returning malformed or effectively random values when too many measurands are configured on that connection (lbbrhzn/ocpp#1487). A separate issue documents chargers sending meter values with a transaction ID of 0, even after a valid StartTransaction confirmation (mobilityhouse/ocpp#478).

Load-management logic that trusts malformed or misattributed meter data will make bad decisions: allocating capacity based on a reading that never happened, or attributing one to the wrong session. Data quality at ingestion is a load-management problem, not a separate concern bolted on afterward. Config-parameter mismatches between the CSMS and charger firmware, like the sampling-limit example above, are a common, underestimated source of bad data reaching the database in the first place. Catching it means validating and flagging anomalous data as it arrives rather than trusting it downstream.

OCPP 1.6 vs. OCPP 2.0.1 for smart charging

Capability	OCPP 1.6	OCPP 2.0.1
Smart-charging profiles	Limited, vendor-extension dependent	Native `SetChargingProfile` support built into the spec
Session/device control granularity	Coarse, per-charger	Granular, per-device and per-session (Device Model)
ISO 15118 (Plug & Charge)	Not natively supported (requires a vendor-specific `DataTransfer` workaround)	Native support

OCPP 2.0.1 is the version with native smart-charging-profile support, and it's the version that matters if dynamic load management is the goal. That doesn't make OCPP 1.6 a dead end: a CPO running static or local load management (fixed per-charger caps, no live feedback loop) can support that on 1.6 today. If the goal is dynamic, granular, or per-session load management, go to 2.0.1; if a fixed cap per charger is sufficient, 1.6 supports that without a protocol migration.

Architecting the database layer for load management

This is the part most vendor and consumer content skips: what the database underneath the decision logic actually needs to do.

Hypertables for high-frequency meter and status data. A continuous MeterValues stream from many chargers is append-only, timestamped, and queried almost exclusively by time range. Hypertables partition this data automatically by time, so a query scoped to "current session" or "last hour" only scans the relevant chunks, keeping ingest and query performance stable as charger count and history grow.

Continuous aggregates for real-time load rollups. The core question a load-management decision needs answered fast is: what's the current aggregate draw across active sessions at this site? Continuous aggregates maintain a rolling summary that refreshes incrementally on a schedule, rather than rescanning raw data on every decision cycle. Enabling real-time aggregation blends the most recent raw readings into that rollup, so the query returns an up-to-the-moment total.

Columnstore compression (hypercore) for long-retention meter history. Load-management systems need historical meter data for billing reconciliation, demand-charge analysis, and capacity planning, but that history is rarely queried at full resolution once it ages past the current cycle. Columnstore compression keeps it queryable without paying full row-store costs on data nobody reads at full fidelity.

Late-arriving and out-of-order data. Chargers with intermittent connectivity buffer locally and flush on reconnect, so meter readings can arrive out of sequence relative to when they were generated. Hypertables handle this correctly because each row carries its own timestamp; ingestion order doesn't need to match event order for the aggregate to be correct once it refreshes.

A simplified illustration of the shape:

-- Meter readings: high-frequency time-series per connector

CREATE TABLE meter_readings (    time         TIMESTAMPTZ NOT NULL,
    site_id      TEXT        NOT NULL,
    charger_id   TEXT        NOT NULL,
    connector_id INTEGER     NOT NULL,
    session_id   UUID,
    power_kw     DOUBLE PRECISION
);

SELECT create_hypertable('meter_readings', by_range('time'));

-- Continuous aggregate: current aggregate load per site
CREATE MATERIALIZED VIEW site_load_current
WITH (timescaledb.continuous) AS
SELECT
    time_bucket('1 minute', time) AS bucket,
    site_id,
    SUM(power_kw) AS total_draw_kw
FROM meter_readings
WHERE session_id IS NOT NULL
GROUP BY bucket, site_id;

For a single small site with a handful of chargers, this full architecture is likely more than needed; a well-indexed standard table can work fine until session and charger count grows. Treat the above as what becomes necessary once naive approaches start breaking down for the reasons covered earlier.

Self-hosted TimescaleDB and Tiger Cloud, Tiger Data's managed service, run the same architecture. Tiger Cloud partitions data into chunks automatically and, once compression and refresh policies are set, runs those jobs automatically, which matters for a CPO team who would rather not run that operational layer themselves.

Single-site vs. multi-site load management

A single-site deployment keeps every charger behind one capacity limit, and the aggregation question is simple: what's the current load at this site. A distributed, multi-site CPO network changes the question: site-level limits still apply locally, but the data model needs a site dimension so the same rollups can answer "current load across all sites" and "which sites are near their capacity limit," for network-level visibility and, in some cases, cross-site coordination.

The underlying storage doesn't change. Queries shift from a single site-level rollup to one grouped by site, with network-level totals computed on top. It's a scaling dimension, not a different architecture.

A note on demand response and utility programs

Load management is adjacent to, but distinct from, utility demand-response and grid programs, which can pay CPOs or site owners to shed or shift load at specific times. Program mechanics, incentive structures, and compliance requirements vary by utility and jurisdiction, and are outside this article's scope.

The focus here is the database and data-architecture question. Demand-response program participation is a downstream business decision layered on top of a working load-management pipeline, not a prerequisite for building one: a CPO can implement dynamic load management for its own capacity-limit reasons and decide separately whether to participate in a utility program.

Decision framework: choosing a load-management data architecture

Choose a single hypertable + continuous aggregate setup if: you're running one site or a few sites, session and charger counts are modest, and you need real-time site-level load visibility without multi-site coordination.

Choose a multi-site aggregation layer (site dimension + network-level rollups) if: you operate a distributed CPO network and need both site-level enforcement and network-level visibility into aggregate load and capacity headroom.

Choose OCPP 2.0.1 as a prerequisite if: you need native smart-charging-profile support, granular per-session control, or ISO 15118 Plug & Charge integration.

A simpler approach may be enough if: you're running static or local load management only (fixed caps, no feedback loop) at very small scale. Don't over-build the architecture above if a fixed cap and a well-indexed table cover the actual requirement.

Migrating into a load-management-ready data architecture

CPOs generally migrate toward a load-management-ready architecture from one of three starting points:

Flat-file or CSV logging. The most common early-stage pattern, and the first to break down. The migration path: consolidate meter, status, and session data into hypertables, add continuous aggregates for the rollups load-management logic needs, and apply columnstore compression to keep long-retention storage costs down.

A single general-purpose relational database with no time-partitioning. This works until meter-value volume outgrows what a standard table and B-tree index can handle. The migration is largely additive: hypertables slot in without a full schema rewrite, and existing session and billing tables generally stay as standard relational tables alongside the new ones.

A split-stack setup (a separate relational database for billing and session data plus a separate time-series database for meter data). The migration here is architectural: consolidating both into one system removes the cross-database join problem and the overhead of running two query languages and two connection pools for what's conceptually one dataset.

Teams migrating from OCPP 1.6 to 2.0.1 at the same time should expect to revisit their charging-profile and session-control data model alongside the database migration, since 2.0.1's native smart-charging-profile support changes what the backend needs to store and act on. Treat the protocol upgrade and the data-architecture work as one project, not two sequential ones.

FAQ

What is dynamic load management (DLM) for EV charging, and how is it different from static load management?

Dynamic load management is a live-feedback system that continuously adjusts charging limits based on real-time meter and session data. Static (or local) load management applies fixed per-charger caps with no feedback loop. Dynamic load management requires a time-series data architecture; static load management does not.

Do EV chargers have load management built in, or does it live in the backend software?

Some chargers support local or static load management at the hardware level. Dynamic, multi-charger, or multi-site load management is a backend or CSMS software function that depends on meter, status, and session data. The charger enforces the limit it's given; the backend calculates what that limit should be.

What OCPP message types does load management logic depend on?

Three: MeterValues for live consumption data, StatusNotification for charger and connector state, and SetChargingProfile for enforcing the calculated limit. Together, these three form the minimum data loop load management needs.

Do you need OCPP 2.0.1 to support smart charging, or does OCPP 1.6 work?

OCPP 2.0.1 added native smart-charging-profile support and is the version built for this use case. OCPP 1.6 can support more limited, static forms of load management, but lacks the same granular per-device and per-session control.

How much charger telemetry data does a load management system actually generate?

Meter-reading frequency and multi-charger session volume compound quickly as charger count grows. A site with dozens of chargers, each reporting on its own interval with its own status and session state, produces a stream that needs to be read in aggregate, in real time, which turns load management into a genuine time-series data problem rather than a simple lookup.

How do you handle malformed or mis-attributed meter values without breaking load-management decisions?

Validate and flag anomalous meter data at ingestion rather than trusting it downstream. Documented failure modes, including OCPP 1.6 chargers not respecting MeterValuesSampledDataMaxLength and chargers sending meter values with a transaction ID of 0 after a valid session start, show that load-management logic acting on unvalidated meter data will make bad decisions.

Is load management different for a single site vs. a multi-site charging network?

Yes. Single-site load management needs site-level aggregation only. Multi-site or network load management needs a site dimension in the data model plus network-level rollups for cross-site visibility and capacity planning.

Does OCPP already handle load management for us?

No. OCPP is the communication layer that carries meter and status data and accepts charging-profile commands. The actual load-balancing decision, what profile to set and for whom, lives in the CSMS or backend.

Can you just log meter and session data to CSV or flat files and reconcile it later?

It's a common early-stage pattern that works at very small scale. It breaks down once session and meter volume grows, because there's no efficient way to query current aggregate load in real time from flat files, which is exactly what a load-management decision needs.

What's the difference between load management and a utility demand-response program?

Load management is the data and technical layer that keeps charging within a site's capacity limit. Demand-response programs are separate, utility-specific arrangements that pay CPOs or site owners to shift or shed load at certain times. Load management is often a prerequisite for participating in such a program, not the program itself.

What database architecture works best for EV charging load management at scale?

Hypertables for high-frequency meter and status ingestion, continuous aggregates for real-time load rollups, and columnstore compression for long-retention meter history. This is the same PostgreSQL-based approach used for the underlying OCPP data model.

How is load management data different from the OCPP data covered in a general EV charging database guide?

A general OCPP data-architecture guide covers storing and querying charger telemetry and billing data. Load management is the additional layer on top of that same data: using it to compute and enforce real-time capacity limits across chargers.