September 10, 2026

How Root Rebuilt Its Telematics Platform for Scale

Written by Joe Plattenburg

Root, the leading technology company in car insurance, was founded around a simple idea: car insurance pricing should reflect how people actually drive. We also strongly believed in meeting customers where they already were, through a mobile-first experience. In 2015, early in the startup phase, we developed a data collection system that could robustly detect driving behavior and measure location, speed, acceleration, and other signals during trips.

To get the MVP off the ground quickly, we did the simplest thing we could: serialize each trip into a JSON file and store it in S3. Those files would then be processed by downstream systems into risk features that could be used in our scoring and pricing models. To be clear, this was a perfectly reasonable solution for an early stage startup still trying to prove product market fit. The problem was that the initial solution proved so robust that we never took the time to reconsider the design and assumptions until we had far outgrown our original scale.

By 2020, the system had grown to support more than one billion trips spanning multiple petabytes of data, while accruing material annual storage costs. Further, technical debt abounded: schemas had diverged between Android and iOS clients; querying the data efficiently was nearly impossible; downstream processing systems were tightly coupled to the exact structure of raw trip payloads. Even locating a specific trip required consulting metadata stored in a database table inside our core insurance application. The storage costs were challenging, but the bigger issue was architectural. Our data model and system design had made telematics data increasingly difficult to access, process, and evolve at scale.

By this point, it was clear that big changes were needed. However, we faced a tremendous challenge in both envisioning what the new state would look like and marshaling support from across the organization to implement those changes.

Technical Plan

We started by defining a few architectural principles:

• Telematics should behave like an independent platform, not an implementation detail embedded inside the insurance application.

• Downstream systems should consume stable, well-defined data rather than source-specific payloads.

• Storage should optimize for large-scale processing and analytics, not just ingestion.

• Costs should be reduced through better data representation, compression, and partitioning strategies.

Once we had articulated these principles, we were able to begin sketching a design for both the new system and the new data model.

Clearly, telematics ought to be a separate entity from the core insurance application, and it would own both the storage and processing. While it may have also been tempting to include the data collection within this boundary, it was important to consider the fact that if Root’s telematics platform was truly going to become a vendor to the insurance business, we may need to collect data from alternative sources (again, perhaps other mobile apps or vehicles). As such, the data collection was kept outside the box, but a new and important concept was introduced: “canonical conversion.”

For every upstream data source, we would define a canonical conversion step:

C_source(X_source) → Y_canonical

Each source could maintain its own native schema, but downstream systems would only interact with the canonical representation. This allowed the telematics platform, rather than individual consumers, to own schema evolution and compatibility over time.

On the data model side, we opted for parquet which provided both richer data types as well as columnar access for efficient querying. We were also able to eliminate some redundancy in our data payloads by reducing the set of sensor measurements to a minimal unique representation.

We retained S3 as the underlying storage layer, but introduced a dedicated indexing and query layer so downstream systems no longer needed direct knowledge of storage layout or object paths. Trips were grouped into larger partitioned parquet datasets to reduce small-file overhead, reduce costs, and dramatically improve analytical query performance. (We’ll dive deeper into the implementation details in the next post.)

None of the above design decisions were groundbreaking, but taken together, they constituted a true phase shift in both system design and data modeling. The technical challenges weren’t even the biggest hurdle. While we had a clear technical direction, we still needed broader support from other leaders that this was an investment worth making, given the delayed ROI and migration risks. The argument that ultimately resonated was less about storage costs than the strategic flexibility needed by the system.

Telematics data was one of Root’s core differentiators, yet the surrounding infrastructure had become increasingly brittle and difficult to evolve. Adding new data sources, enabling large-scale experimentation, or supporting new analytical workflows required navigating years of implicit assumptions embedded across storage, processing, and downstream systems.

In other words, one of our most valuable assets was gradually becoming operationally inaccessible. Canonical data gave us a path to reverse that trend.

Implementation

Even with a strong architectural direction, execution was still enormously challenging. The migration required us to:

• build a canonical conversion pipeline for legacy trip data

• redesign downstream processing to efficiently consume the new format

• validate that the migration was lossless,

• and ensure that the predictive power of our scoring models remained unchanged.

All of this had to happen without interrupting the existing system. Or, to put it another way: we had to build the Ferrari while driving the Civic.

Fortunately, we were able to validate both the conversion pipeline and downstream processing logic on smaller datasets before beginning the full migration. That iterative testing process proved invaluable. In several cases, it surfaced tiny but consequential discrepancies (as subtle as a missing negative sign in a sensor transformation) that could have silently altered downstream model behavior at scale.

Even with extensive validation in place, there was still an unavoidable moment of tension when it came time to begin the full historical migration. Years of accumulated telematics data would be extracted from archival storage, transformed into the canonical format, and reprocessed using the new pipeline, after which time the legacy data would be permanently deleted. At that point, correctness stopped being theoretical.

The final verification step was comparing predictive outputs between the legacy and canonical systems at scale. When the results aligned as expected, it was a massive collective relief. In the capstone presentation, the graph showing the final performance metrics even elicited a celebratory emoji from our CTO. We had successfully rebuilt the foundation of the platform (including delivering very real cost savings, as highlighted below) without sacrificing the integrity of the underlying models.

Results

From a purely operational perspective, the project exceeded our expectations, as seen from the annual cost figures:

But these really don’t tell the whole story.

Under the original architecture, achieving “acceptable” storage costs required aggressively archiving the vast majority of historical data into Glacier Deep Archive. While technically retained, much of that data had become operationally inaccessible. Running large-scale analyses against historical trips was cumbersome, expensive, and often impractical.

In the new system, even after reducing storage costs by roughly 4x, all historical trip data became immediately queryable through standard analytical tooling. What had previously required specialized operational support could now be accomplished through straightforward SQL queries.

The compute improvements were arguably even more significant. Before the migration, processing costs were high enough that only a fraction of historical trips were evaluated using our newest feature extraction and scoring pipelines. We had effectively accumulated years of underutilized telematics data while waiting for a more scalable processing model.

The canonical platform fundamentally changed that equation. We were able to process 100% of historical trips using our latest algorithms while still dramatically reducing compute costs. More importantly, researchers and data scientists could now experiment on the full historical dataset rather than carefully constrained subsets. One research initiative that had been postponed for years due to computational costs was completed just a month after the data migration. The infrastructure shift truly expanded the set of questions we were capable of asking.

Conclusion

Looking back, the project reinforced several lessons about large-scale systems and long-lived infrastructure.

First, startup architectures almost always outgrow their original assumptions. The more consequential decision is deciding when is the right time to undertake them. Move too early, and you risk over-engineering for a future that may never arrive. Move too late, and both the technical complexity and organizational inertia become dramatically harder to overcome. In our case, we almost certainly erred on the side of waiting too long (though, likely the safer mistake for an early-stage company focused on finding product-market fit).

The migration also reinforced an important reality about infrastructure work: performance improvements alone are never enough. Large-scale data migrations also require proof of correctness. In our case, small-scale validation was necessary but ultimately insufficient. Some guarantees could only be established once the full migration was completed and the new platform was operating against the complete historical dataset.

Most importantly, the project changed how we thought about data accessibility. Storage and compute efficiency matter, but accessibility is just as important. Data that is technically retained but burdensome to query might as well not exist at all. By making historical telematics data broadly accessible through standard analytical tooling, we significantly expanded the kinds of research and experimentation the organization could perform. That shift enabled us to answer entirely new classes of questions that had previously been too expensive or onerous to explore.

Ultimately, we achieved our cost-savings goal while successfully building a durable platform for the future of telematics at Root.

In our follow-up post, we’ll dive deeper into how we designed the canonical data model and migrated billions of files, totaling multiple petabytes, losslessly and without interrupting downstream systems.