13 years ago, in 2013, I got to beta test one Google’s “Self-Driving Cars.” You might know them today as Waymos. The Self-Driving Car of 2013 could only self-drive on freeways, and only freeways near Google. We took it from Mountain View to Sam’s Chowder House in Half Moon Bay (using the self-driving features for the Highway 101 portion of the trip, then taking the wheel for the windy Highway 92 section), had dinner, then took it home.
In that moment, I was completely converted to the idea of self-driving cars. Not having to sit in traffic is … immensely appealing. Not to mention, autonomous vehicles (AVs) are likely to be significantly safer than human drivers.
Today, Waymos are providing 500,000 rides a month, operating in 11 cities, and covering 1,400 square miles. The possibility of an autonomous future is increasingly real.
Many people remain concerned about how the car makes decisions. The new Waymos have 20+ sensors - where does that data go? In this blog post, I explore what data management capabilities are needed onboard an autonomous vehicle and what the implications are for safety.
Every autonomous vehicle is a high-performance computing platform with substantial onboard processing and storage. Those resources are essential, because the vehicle must continue operating safely - regardless of the state of its network connection. That means that a lot of the hardware needs to be on the vehicle itself (vs, say, in the cloud).
Why can’t data storage & processing occur in the cloud? In short, connectivity & latency. Modern autonomous vehicle cannot assume continuous connectivity. Cellular coverage varies across highways, tunnels, parking structures, rural areas, and disaster zones. The vehicle must therefore be designed to operate independently for as long as necessary. Connectivity improves the vehicle over time through software updates, fleet learning, and map updates, but it cannot be a prerequisite for safe operation.
What does that mean for hardware requirements on the vehicle? What is needed from a safety perspective?
I’m going to geek out a bit here, because I think this is really cool.
Every second, an autonomous vehicle processes information from cameras, radar, lidar, GPS, inertial sensors, and dozens of other vehicle systems. It combines these inputs into a single view / perspective about its surroundings, identifies other vehicles and pedestrians, predicts how they will move, determines its own position, plans a safe path, and controls steering, braking, and acceleration to respond to what it understands.
How does it collect this information? As an example, a 6th generation Waymo Driver has 23 primary core sensors plus external audio receivers.
13 Cameras: Optimized surround-view high-resolution cameras.
4 LiDARs: Upgraded perimeter and main LiDARs with enhanced range and resolution.
6 RADARs: Advanced imaging radars for all-weather perception.
External Audio Receivers (EARs): Array of specialized microphones for audio detection.
This is down from 40 sensors on the 5th generation car - which is such an insanely high number - and an insane amount of information to collect.
The vehicles also gather data - via 5G cellular networks - about where other cars in the fleet are, where traffic jams may be, and other “real time” information that may not be available in its immediate vicinity from its sensors.
For the most part, onboard the vehicle. The onboard platform is responsible for the vehicle’s entire real-time operating environment. Cloud infrastructure supports the vehicle over its lifetime, but it does not participate in immediate driving decisions, instead supporting post-trip analyses.
Why can’t we use the cloud to do real-time processing?
Connectivity is unreliable. Vehicles regularly lose connectivity, e.g. in underground parking garages, in tunnels, on mountain roads, in severe weather, or at my house in the Bay Area (T-Mobile, you are welcome to stop by any time to address this!)
Every driving decision has to be made within milliseconds. Even a brief delay could have safety consequences.
It’s tempting to think of losing connectivity as an exception. In reality, it’s an assumption that engineers make to inform design decisions.
So, let’s assume for this post that a significant portion (if not all) of the real-time decision-making happens in the car.
Basically, the cameras are the data hogs. They account for over 90% of the storage an autonomous vehicle needs.
The above rates of collection imply that each vehicle would need about 1,000 TB (1 PB) to store one day’s worth of data. However, only about 4-5 TB of storage capacity is put into each vehicle (10TB+ for for Level 5 (complete) autonomous driving).
If 1 PB of data per day is created, how is 4 TB of onboard storage enough? A couple of things are happening to the data:
Real time inferencing. AI processes images in milliseconds, and discards extra information (e.g. the raw pixels) immediately after a vehicle makes a navigation decision. This saves space immediately.
Buffering. The onboard storage is treated primarily as a rolling buffer, keeping only the last 30-60 minutes of compressed driving video. As the car drives, old data is overwritten. However, if a crash (or other critical event) occurs, the system will “lock” the relevant portion of the data to prevent overwriting, so a human can review it later.
Offloading the data. When cars like Waymo are done with their shifts, they return to depots. They’re connected to high-speed cables to dump their data into the cloud for processing & model retraining . Notably, this information offloading doesn’t happen over 5G, because that would be both slow and expensive to upload terabytes of data over cell networks. (Again, I just want connectivity for my cell phone at my house, so let’s start with that before moving on to 23 sensors worth of driving data).
In summary, there is a lot of data processing that is occurring to reduce the onboard storage load.
So we only need 4 TB of storage. What, then, is that 4 TB used for?
Operational logs and ring buffers (up to 2,000 GB). This is what most of the storage is used for. Vehicles continuously generate diagnostic information, cybersecurity events, system telemetry, and sensor recording- this information is stored locally until it can be uploaded back at the depot.
High-definition (HD) maps (up to 250 GB). These maps include lane geometry, traffic controls, road topology, speed limits, and other information used for localization and navigation. Generally, this stays on the vehicle.
Machine learning models (up to 200 GB). The models responsible for perception, object detection, localization, prediction, planning, and control, and are stored onboard so they can execute without network access.
Software and operating systems (~50 GB). The complete software stack required to operate the vehicle must remain available locally, including recovery images and safety-critical software.
Navigation databases (~30 GB). Routing information, charging locations, and destination data that must remain available while disconnected.
All of these data management decisions are made to enhance rider safety. Specifically:
The car is not dependent on cell service to be able to navigate. Storing all HD maps, ML models, and operating software directly on the vehicle guarantees the car drives safely anywhere—even in dead zones, tunnels, or cellular network outages.
The car can react quickly to new information. Storing and processing sensor data locally avoids the unpredictable delays of cloud communication, allowing the car to make life-saving decisions in under 100 milliseconds.
Information about critical events is retained: Rolling buffers lock data during rare edge cases or near-misses; when offloaded at the depot, these logs are used to train the software and make the entire fleet safer overnight.
Potential hacking vectors are reduced: Running driving algorithms offline closes off external hacking vectors, while discarding raw video locally ensures passenger and pedestrian privacy isn’t compromised.
For infrastructure providers, this represents another significant edge computing opportunity. Demand extends - beyond processors - to include storage systems, memory technologies, networking components, software platforms, and lifecycle management tools that support autonomous operation.
100 million cars are sold per year. Some increasing fraction of those have autonomous capabilities. The market is there for this use case.
Autonomous vehicles demonstrate how computing and storage capabilities are becoming increasingly distributed. Rather than relying exclusively on centralized infrastructure, they combine cloud-scale computing with substantial processing and storage at the edge.
That architecture reflects the operational requirements of the application. A vehicle cannot depend on continuous connectivity to make driving decisions, so it must carry the resources required to operate independently.
As more industries deploy intelligent systems outside traditional data centers, autonomous vehicles provide one of the clearest examples of how edge storage and computing is becoming a foundational part of modern infrastructure.
No posts

Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.