BMW's Cloud Data Hub Ingests 110 Terabytes a Day. Here's the Trick.

20 million connected BMWs. 110 terabytes of data a day. Just 5.5 megabytes per car.

BMW Group's Cloud Data Hub, hosted on Amazon Web Services, is one of the largest publicly documented automotive data operations in the world. It manages 20 petabytes of storage, spans 6,400 internal data assets, and ingests 110 terabytes of telemetry every single day from 20 million connected vehicles globally. Do the division, though, and something interesting shows up: that works out to roughly 5.5 megabytes of curated telemetry per vehicle, per day. For a modern car generating hundreds of gigabytes of raw sensor data daily, that's a strikingly small number.

Where all that raw data actually goes

A modern connected car monitors more than 200 telemetry parameters continuously - powertrain diagnostics, battery cell temperatures, brake friction coefficients, steering angles, tire pressures, forward-facing camera feeds, radar object lists, precise GPS positioning, and more. Across the vehicle's Controller Area Network, Local Interconnect Network and automotive Ethernet buses, this adds up to between 15 and 25 gigabytes of raw operational data for every hour the car is driven.

If you tried to send all of that straight to the cloud over a cellular connection, the economics would collapse almost immediately. Mobile network transit charges, cellular throttling, and cloud ingestion costs at that volume, multiplied across millions of vehicles, would make the whole enterprise commercially impossible.

The car doesn't send everything it sees. It decides what's actually worth telling the cloud about.

— Marqstats Analyst Team

How the filtering actually works

The solution runs on the car itself. High-performance domain controllers and intelligent Telematics Control Units execute embedded software, built on standards like AUTOSAR Adaptive or embedded Linux, that monitors those continuous sensor streams locally, at frequencies between 50 and 100 times per second. This onboard software runs local filtering algorithms and extracts genuinely meaningful events while discarding the enormous volume of routine, unremarkable baseline telemetry that doesn't need to leave the car at all.

Cellular transmission only kicks in when specific, predetermined triggers occur - sudden deceleration, anti-lock braking activation, a battery thermal spike, or a scheduled diagnostic summary sent on a fixed interval rather than continuously. This is the mechanism behind the compression ratio exceeding 6,800 to 1: for every 6,800 units of data the vehicle's sensors generate, roughly one unit actually makes the trip to the cloud.

Why this scaled the way it did for BMW specifically

BMW's own deployment illustrates how this scales in practice. The Cloud Data Hub didn't start at its current size - it began by handling 10 terabytes of daily telemetry from 1.2 million vehicles. As the connected fleet grew to 20 million vehicles, daily ingestion grew to 110 terabytes, but the growth in data volume tracked the growth in fleet size in a roughly proportional way, rather than exploding disproportionately, precisely because the per-vehicle filtering approach kept each individual car's contribution small and predictable.

The counter-argument: does aggressive filtering mean useful data gets lost?

A fair question is whether this level of filtering, discarding the overwhelming majority of raw sensor output before it ever reaches analysis, means genuinely useful signal gets thrown away along with the noise. This is a real trade-off. The filtering rules embedded in the vehicle's edge software make judgment calls about what counts as a meaningful event, and any such rule set will inevitably miss some patterns that a full, unfiltered dataset might have revealed, particularly for rare or previously unanticipated failure modes. The industry's response has generally been to make these filtering rules increasingly sophisticated over successive vehicle generations, but the fundamental tension between wanting complete data and needing commercially viable transmission costs is not something that goes away - it is a permanent design constraint, not a problem awaiting a final solution.

What this means for anyone building or evaluating connected vehicle infrastructure

• Evaluate any automotive cloud platform's edge filtering methodology specifically, since it determines what data will and will not be available for downstream analysis or third-party access.
• Treat cellular transmission cost as a first-order architectural constraint from the earliest design stage of any new connected vehicle program, not an optimization to address later.
• Track how filtering rules evolve across vehicle generations, since increasing sophistication there, more than raw compute scale alone, is what will determine how much useful signal future systems can capture.

The full market picture

Marqstats' complete Europe automotive data management market analysis, including the full edge-to-cloud architectural pipeline, is available in the linked report below.