Swiss Fast Charging Data Puts Tesla Superchargers Ahead of IONITY, but the Real Story Is Systems Design

Problem

A comparison published on DEV Community claims a measurable gap between Tesla Superchargers and IONITY fast chargers in Switzerland, based on charging sessions collected across 2023 and spot checks in early 2024. The headline numbers are simple enough: Tesla sessions averaged 215 kW, IONITY sessions averaged 93 kW, Tesla sites showed lower average occupancy, and the reported effective cost per useful kWh was better on Tesla’s network.

The more useful reading is not that one plug is magically better than another. Fast charging is a distributed system with physical constraints. Every session is shaped by vehicle state of charge, battery temperature, charger cabinet allocation, site occupancy, local grid capacity, pricing, billing measurement, and backend availability data. A 250 kW or 350 kW label is a maximum under favorable conditions, not a service level objective.

The article’s data pipeline reportedly used the Tesla Fleet API and IONITY charging session data, then aggregated sessions in Snowflake before exporting CSV data for analysis. It filtered out charges below 10 kWh and sessions where ambient temperature changed materially between departure and arrival. After filtering, the reported sample contained 31,872 Tesla sessions and 9,415 IONITY sessions.

That filtering matters because charging curves are not stable functions of charger rating. A cold battery, a high starting state of charge, shared power cabinets, and a busy site can all make a nominally high-power charger behave like a slower one. Anyone who has operated production systems will recognize the pattern: peak capacity sells the system, but tail behavior defines user trust.

Solution Approach

The useful approach is to treat EV charging telemetry as event data, not as a static benchmark. Each charging session is a time series with at least four key dimensions: vehicle context, charger context, energy accounting, and station occupancy.

Vehicle context includes state of charge, battery temperature, preconditioning status, vehicle model, pack chemistry, and requested charge limit. Charger context includes dispenser rating, cabinet topology, shared power rules, grid-side limits, and derating events. Energy accounting includes billed kWh, delivered kWh, session start and stop time, and conversion losses. Station occupancy includes available stalls, blocked stalls, queue time, and concurrent demand.

The DEV article reports that Tesla averaged 215 kW across comparable Model 3 Long Range sessions, while IONITY averaged 93 kW. If the measurement method is sound, that is not a small operational delta. On a long trip, it changes routing strategy. A driver does not experience average annual station power. The driver experiences a sequence of waits, plugs, stalls, derates, and billing records.

This is where API design becomes part of the product. A charging network has to expose enough state to support planning, but that state is only useful if clients understand its consistency model. A station availability API is usually an eventually consistent read model. It may say two chargers are free, while one was just occupied and another is faulted but not yet reported. A billing API is closer to a source of record, but it may still finalize asynchronously after meter reconciliation. A route planner has to combine both without pretending the data is stronger than it is.

A sane API model for this domain would separate commands from observations. Availability endpoints should carry timestamps, confidence, stall-level status, and freshness metadata. Session endpoints should use stable identifiers and idempotent state transitions such as started, energy-delivering, paused, stopped, billed, and reconciled. Billing endpoints should avoid overwriting final records silently. Corrections should be append-only events or explicit adjustments, because payment data needs auditability.

This is also where OCPP matters. The Open Charge Point Protocol gives charging stations and central systems a common control and telemetry language. It does not remove every operational difference, but it gives operators a shared vocabulary for sessions, meter values, authorization, smart charging, and device state. Networks that combine proprietary systems, roaming partners, payment processors, and physical chargers need that kind of protocol boundary or they end up with brittle integrations.

Tesla has a structural advantage because it controls more of the stack. The Supercharger network integrates vehicle software, route planning, charger telemetry, preconditioning, authentication, billing, and user experience. The vehicle can be told to heat the pack before arrival. The planner can prefer stations with better expected throughput. The payment path is mostly invisible to the driver. This is vertical integration doing practical work.

IONITY, by contrast, is a pan-European network serving many vehicle brands, payment flows, roaming providers, and battery architectures. Its official network is designed around high-power CCS charging, but the end-to-end path from car to charger to account is more heterogeneous. That does not make it inferior by design. It does mean the control loop is wider, with more contracts and less shared context at the point of charge.

What The Reported Numbers Change

The article reports a Tesla efficiency factor of 0.94 kWh delivered per billed kWh, compared with 0.78 for IONITY. If interpreted literally, that is a large difference. For a driver, it means the posted price per kWh is not the full economic story. A cheaper tariff can still lose if more energy is consumed in conversion losses, thermal overhead, or session inefficiency.

The reported Swiss prices were 0.32 CHF per kWh for Tesla and 0.39 CHF per kWh for IONITY. On a Zurich to Geneva trip, the article calculated 21.4 CHF on Tesla versus 28.5 CHF on IONITY for the sample table. Across a month of 800 km, it estimated roughly 45 CHF and 1 hour 15 minutes saved with Tesla.

The time component is usually more important than the energy component. In distributed systems terms, this is latency, not just throughput. A charger that can theoretically deliver 350 kW but often delivers less than 100 kW under load has poor effective latency for trip completion. A network with more stalls, better prediction, and lower occupancy can beat a higher-rated charger that is frequently saturated.

The reported occupancy gap points in that direction. Tesla sites averaged 12 percent occupancy, while IONITY averaged 38 percent. Average occupancy can hide peaks, but it still suggests different capacity margins. A station at 38 percent average utilization may look fine in annual planning, yet still produce queues at commuter peaks, holiday windows, and ski-route surges. Queueing theory is not kind to systems that run near capacity with bursty arrivals.

A charging site has the same failure mode as any shared resource pool. Once utilization rises, wait time grows nonlinearly. If arrivals cluster and service times vary, small capacity shortages become visible fast. This is why site density matters. Adding chargers is not only about total daily kWh. It reduces tail latency for the unlucky driver who arrives behind three vehicles with cold packs and high charge targets.

Trade-Offs

The Tesla model trades openness for control. A tightly integrated vehicle and charging network can optimize across layers that are usually separated. Route planning, preconditioning, stall selection, billing, and charger telemetry can all feed one decision engine. The downside is dependency on a single operator’s rules, pricing, account model, and access policies.

The IONITY model trades control for interoperability. It supports a broader ecosystem across brands and roaming relationships. That makes it more valuable as shared European infrastructure, but harder to tune for one vehicle class. When the car, charging network, payment provider, and navigation system are owned by different parties, the system needs stronger contracts at every boundary.

Those contracts should be explicit. Station status should not be a vague online or offline flag. A useful charging API should expose current dispenser state, connector type, max currently available power, recent derating, queue estimate, price, payment methods, Plug & Charge support, and last update time. Clients should be able to tell whether they are looking at live telemetry, a cached read model, or an operator-provided estimate.

Consistency matters because route planning is a read-your-writes problem for the driver. If a driver starts navigation and the planner reserves no capacity, the availability data is advisory. If the network supports reservations, then the API needs stronger semantics: expiration, cancellation, idempotency keys, conflict handling, and clear failure modes. A half-reserved charger is the infrastructure equivalent of a split-brain lock.

Billing is a different consistency problem. A session can end before the final metered value is reconciled. The user interface wants an immediate receipt, while the accounting system wants a final number. The clean pattern is to show a provisional session summary, then finalize through an immutable billing event. Overwriting the number later without a correction trail is how trust gets damaged.

The data pipeline has similar risks. A Snowflake-backed analysis can scale well for batch analytics, but the quality depends on event definitions. If Tesla and IONITY expose similar metric names but measure them at different points in the chain, direct comparison gets slippery. Billed kWh, charger output kWh, vehicle-received kWh, and battery-stored kWh are not interchangeable. A serious benchmark needs schema documentation, unit definitions, sampling rates, missing-data policy, and confidence intervals.

There is also a selection-bias problem. The article compares Model 3 Long Range sessions, which helps control the vehicle side, but charger choice is not random. Drivers may choose Tesla sites for certain routes, times, or trip patterns. IONITY sessions may include different congestion patterns or non-ideal routing behavior. Filtering temperature and short sessions is useful, but it does not remove every operational bias.

Broader Pattern

The broader lesson is that EV charging networks should be judged like production infrastructure. Peak rating is capacity. Average delivered power is throughput. Wait time is latency. Failed sessions are errors. Derating is backpressure. Pricing is not only cost, it is load shaping. Route planning is a distributed scheduler with stale reads.

Tesla appears to win in this dataset because it has more control over the scheduler and more spare capacity in the sampled Swiss network. IONITY’s challenge is harder because it coordinates across more independent actors. That makes API discipline and protocol clarity more important, not less.

For operators, the target should be user-visible service objectives rather than charger-spec marketing. Publish expected power by state-of-charge band. Expose station freshness. Show derating when it happens. Treat billing records as auditable events. Design APIs so third-party route planners can make good decisions without guessing. Build capacity for peak demand, because averages do not wait in line.

For drivers, the practical outcome is simpler. In the reported Swiss sample, Tesla Superchargers delivered faster sessions, lower waits, and lower effective trip cost than IONITY. The technical reason is not just plug power. It is the full control loop from telemetry to routing to power allocation to billing. Fast charging is no longer only an electrical engineering problem. It is a distributed systems problem sitting beside a highway.