Real-Time Data Platform for Racing: Trackhouse and Databricks with ZeroBus

Summary

Trackhouse Racing, a NASCAR team with just five developers, consolidated data from 25+ racing systems into a unified lakehouse on the Databricks Data and AI platform using medallion architecture, Safety Culture integration, and ZeroBus real-time streaming.
In year one, batch pipelines linked pit crew metrics with video telemetry to reveal performance bottlenecks; in year two, ZeroBus streaming at 1M+ messages per second enabled live race strategy decisions.
The architecture demonstrates how small, focused engineering teams can deliver competitive data-driven performance platforms by choosing managed infrastructure that eliminates operational overhead.

Real-Time Data Platform for Racing: Trackhouse and Databricks with ZeroBus

NASCAR teams manage hundreds of terabytes of sensor data weekly from race cars, simulations, pit stops, and vehicle builds. But this data remains siloed across 25+ racing systems with proprietary formats, locked APIs, and incompatible databases. Trackhouse Racing faced a critical problem: they processed race data for weeks after events, unable to influence outcomes. Building a competitive data platform required consolidating this fragmented data in real-time while maintaining a small team of five developers.
See how Trackhouse and Databricks built a unified racing intelligence platform in 12 months using medallion architecture, Safety Culture integration, and ZeroBus real-time streaming. Learn how pit crew metrics linked with video telemetry revealed performance bottlenecks, how ZeroBus eliminated infrastructure overhead, and how streaming data at 1M+ messages per second powers live race strategy decisions. This case study shows how small, focused teams win with data-driven architecture.
🤝

Chapters

FAQs

What data challenges did Trackhouse Racing face before adopting Databricks?

Trackhouse Racing managed data across 25+ racing systems with proprietary formats, locked APIs, and incompatible databases, resulting in silos that prevented real-time decision making during races. Race data was processed for weeks after events, making it impossible to influence outcomes in the moment.

How does ZeroBus help with real-time racing data?

ZeroBus is a streaming solution that eliminates infrastructure overhead and processes more than 1 million messages per second, enabling Trackhouse to move from batch architecture to real-time streaming pipelines. This shift allowed live race strategy decisions to be made during events rather than weeks afterward.

How did pit stop analytics improve Trackhouse Racing's on-track performance?

By linking pit crew metrics with video telemetry in their Databricks-based platform, Trackhouse was able to identify specific performance bottlenecks in pit stop execution. Pit stop performance is directly tied to the team's key business metrics: trophies and prize money.

How did a five-person team build a production data platform for a NASCAR team in 12 months?

Trackhouse Racing's team of five developers leveraged the Databricks Data and AI platform and ZeroBus real-time streaming to build their unified racing intelligence platform in 12 months. By using managed services that eliminated infrastructure overhead, the small team could focus on data analysis applications rather than operations.

Full transcript

[00:11] From the entire team at Trackhouse Racing, thanks to all of you for coming today. We're very excited to share our journey as a NASCAR team on the Databricks platform. But before I do that, we all know complex projects like this couldn't come off without contributions from everyone.
[00:26] So, thanks to the entire Trackhouse team for helping get us to get us to where we are today. Uh a little introduction to me. I'm Chris Chris Ebaly. Uh I started my career in aerospace, but I've since spent 20-plus years in motorsport software engineering.
[00:42] I've worked in different IndyCar teams, NASCAR teams, and an auto manufacturer. And I've been fortunate to win several championships and the Indy 500 along the way. But in terms of software engineering, I imagine I followed a similar career path to many of you in the room today, starting with desktop application
[00:59] development, deploying some of that onto cloud platforms, and now into fully integrated data platforms to take advantage of the scale that we have available to us. I had built some Databricks solutions at previous employment, and Trackhouse was looking to stand up their own integrated
[01:14] data and AI platform. So, I was brought in to kick off that activity. Who are we at Trackhouse Racing? Well, we are software engineers. We have a relatively small team. We're about five developers, but we have a lot of experience writing highly specialized
[01:30] data analysis applications. We are also race engineers who determine the vehicle setup every time the car leaves the pits. They have an exhaustive simulation and analysis process, but they're traveling every week to 38 different races a year, and that
[01:45] compressed timeline really drives a lot of our operations as a company and also as a data platform. We're also mechanics who build the cars to extremely high standards of reliability and performance. And remember, they're building three to five
[02:00] cars for each of 38 race weekends a year. It's a really very daunting task. And to do that, they use some process tracking software, which we'll discuss a bit later on. We are also the pit crew. You will see them on TV performing the pit stops for
[02:16] us. And their performance in executing those quits pit stops quickly and efficiently has a huge impact on our success or failure at the racetrack. And also our most important business metrics, which are trophies and
[02:31] prize money. So, we were founded in 2022. We're a relatively young organization. We race primarily in NASCAR, uh which is a US domestic sport with strong TV numbers, and in MotoGP, the premier international
[02:47] motorcycle racing series. Some details on NASCAR specifically. Again, we're racing every week from February through to November. Uh we have extremely strong TV numbers, and anyone who works in advertising will tell you that that's an increasingly impactful
[03:03] way to reach uh potential customers. Some fun shots from our media department of track action on the left. And then on the right, we have a car that's come back to us from the racetrack. That was from the Coca-Cola 600 last year, one of
[03:18] the longest and most prestigious races on the calendar. We were lucky enough to win that one, and we we love seeing it in the confetti because we have won that trophy. Uh some details on MotoGP. Uh truly global fan base, and they've recently been taken over by the owners
[03:34] of F1. So, if you, like many people have recently, have discovered F1 through the Netflix series Drive to Survive, we think that you'll love MotoGP as well.
[03:49] You can see here the global scope of the races in MotoGP on five different continents. And then some fun action shots from our media department here from the recent race in Austin, Texas. You can see the incredible lean angles that the bikes get. It's very, very thrilling to watch.
[04:07] I highly recommend it. But we couldn't do any of that or indeed work with platforms like Databricks without our partners. We're very fortunate to have this wonderful collection of partners across both of the series that we work in. And if you would like to join that list,
[04:23] please contact our sales department or come see me afterwards. We're genuinely collaborating with many of our partners on various data and I data and AI initiatives. It's a great win-win. There's good exposure and there's a lot of data for us to collaborate on and tell a really good story.
[04:40] You never know, we might actually be up here talking about it next year, too. So, let's talk about our journey onto an integrated data platform. And we'll begin by discussing the data that we have. So, we have logged data on the car. There are sensors all over
[04:56] measuring different pressures, temperatures, loads, slip angle of the tires. We have inertial measurements and GPS and all of this is logged at very, very high data rates. We also have very detailed vehicle models that can run simulation for us.
[05:11] We can run virtual laps with any setup and any driver line that we like. We're creating a lot of the same data as that logged data, but actually quite a bit more because there's places we can't physically install sensors in the car or we're not allowed by rule. And we can address that through simulation.
[05:28] So, we're routinely running hundreds of thousands if not millions of these for each race weekend that we prepare for. And then much as the NFL or the NBA might, NASCAR provides us with telemetry from each car. So, we have kind of similar content to the data we've been
[05:43] discussing so far, but crucially we have it for everyone in the field, so we can perform symmetrical analysis on all of our competitors. We also have a lot of data from our pit team, which we'll get into a bit more detail later.
[05:59] And for each pit stop we do, and there's five to 10 per car times probably five cars times 38 race weekends a year, we're generating large volumes of metric data and also video from each athlete. We are also, every time the car leaves
[06:14] the pits, we're measuring hundreds of parameters on the car that we call the setup of the car, and these determine the grip, the balance, and the performance of the car out on track. It's really foundational data for us in our data estate. And then, in addition to these kind of raw layers, we also have reports from
[06:31] many different sources, internal and external, that add a human intelligence layer that we also need to capture in our data lake. So, all this data that we've been discussing, it is unfortunately siloed by its sources. We have a lot of racing
[06:47] specific file formats in motorsports. We might have an API that decodes it, but that API might be locked on certain compute platforms. And we also have access to several different databases, but each of those is designed by a separate organization for a separate purpose with a separate
[07:03] custom schema, and there's really no way for us to unify this data that's off-the-shelf. So, if we wanted to look at that data in the past, we were using vendor-specific software, but that's inherently limited in scope. We were writing our own dedicated
[07:18] analysis apps, but that's inherently limited in scale. Or we were standing up our own databases, but then we're working on platform build rather than the data analysis that we need to do to be competitive. And so, really this had been the state of motorsports data analysis for the
[07:33] past decade or two. We had an ever-growing volume of data that we could address, but we ended up with hundreds and hundreds of gigabytes from each race that we really didn't have much visibility to. And so the conclusion from that is that we need a unified platform to de-silo all of that
[07:49] data. So, we started with requirements for selecting a platform. I know that we are speaking at a Databricks conference, but I won't tell you which one it was. But most importantly for us, we needed a single place to de-silo all of that data
[08:05] no matter what source it came from. We also need to unlock the scale of data that we already have. We were not even opening 99% of the data that was available to us because of the limitations of our previous analysis methods. We also know that we need to enable
[08:21] modern analysis tools and AI workflows, but we have a smaller team, so we don't have a lot of capacity to dedicate to ML tooling, SQL servers, this kind of thing. So, yes, we did we did select Databricks, but bearing in mind our
[08:36] requirements and our team size, we'd wanted to design our Databricks to be for us a single point of ingestion, ETL, correlation between all of the data sets, and storage for our data. We wanted to provide also all the tooling for those AI applications and identity and governance, which, you
[08:53] know, for us we're a very time-compressed industry. I think we we often overlook the the governance part of the data, but this data that we're putting into Databricks is our competitive advantage, and we need to secure that for the long term.
[09:10] So, for year one, we started with batch ingestion after the race had completed, but since we had all this proprietary source data, we had to write our own custom application, which would open the data source, process that to a JSON schema we designed, store that in cloud storage, and then use a pipeline to instantiate that into
[09:27] Databricks tables. So, let's critique that year one approach. Well, we write the whole thing. It can look however we need it to look, and the right three quarters of the graph there is vendor unlocked, which is the point of the exercise in the first place.
[09:44] But on the bad side, we have to write all of that. We're a small team, it's a high dev course dev cost, excuse me, for each of these data sources. We're extending the application, designing a schema, and then writing a pipeline all just to get that into Data Bricks in the first place before we do the interesting stuff with it. And then repeat that for
[10:01] each data source. So, the other fact that's buried in that architecture diagram is that we have two copies of the data in cloud storage, which is somewhat wasteful. So, keeping that in mind, let's look at some of the specific data
[10:16] that we are putting in. One of our most important sources is Safety Culture. It's a Safety Culture is a process tracking software company. They started with us as a commercial partner, but we've really grown with them, and we're now using their platform to
[10:31] document in our entire car build process. So, Safety Culture provides for us a place where we can define checklists, we can record measurements, and serve notifications all to our shop floor employees where they're working as they're working.
[10:47] And this is really a crucial part for us of our car build process. We have more than 50 fabricators, build and assembly technicians, and we need visibility into that build process because they're building three to five cars a week for each of excuse me, for each of 38 race weekends a year, and we need
[11:05] that visibility in order to assure quality of that process. And really my favorite part, as we're scraping that data into Data Bricks, we're relating that with our engineering and simulation data, and we really are gaining a much more complete picture than we used to have of how and why the
[11:21] car performs on the track. So, if you were on the team, you might be helping us, and you might see an inspection like this. This is a teardown. After the race is over, the car comes back to us, we take it apart, and here we're going to
[11:37] catalog the condition of all the parts that we see. And then on the left here, you can see an actual completed version of that teardown. And anything that you see in red or pink, unfortunately, has died. We can no longer use it, but that is that's
[11:53] just a hazard of the job. And then on the right-hand side, you can see the number of checklists we have open grouped by the events were preparing for from some point earlier in this year. So, you can see the extent to which we are using this data, not only to track the process, but to drive data
[12:09] into our data bricks. One of the most exciting applications, though, for our data platform has been the pit stop department. So, they are about 40 athletes, three coaches, two
[12:25] engineers, and two athletic trainers, and they're performing five to 10 pit stops for each of probably five cars for 38 race weekends a year. So, when we do a pit stop, we can do several things differently. We can
[12:41] change different numbers of tires. We can change two or four, sometimes zero, but that's that's that's less common. The more tires that we're changing in the pit stop, though, the longer the pit stop takes. The athletes are doing more things, but those tires lose performance over the course of their lives, so the
[12:56] lap times slow down, and we need to make that data-driven decision to know if it's worth the trade-off of a slower pit stop in the performance that we'll gain afterwards. Similarly, that car setup that we discussed earlier, we can change a few of those parameters during a pit stop.
[13:12] Same story as the tires. We are doing more things, so it's going to slow us down, and we need to know if that is going to be a net benefit for us. So, we're generating hundreds of these numerical metrics for each pit stop. We
[13:27] also have video from each athlete. They have helmet cameras. We have overhead views, which I will show you very here shortly here. Uh but really this data prior to Databricks was just like any of the other engineering data we've discussed. We were possibly writing a Python's uh Python app, possibly jamming it in a
[13:44] spreadsheet, but really missing a lot of the conclusions that were hidden in the scale of the data. So, the fun parts. This These are our actual pit stop videos from our races earlier this year. I will let that run.
[14:00] Yeah, there we go. So, this is going to be a pit stop. We're going to change four tires, but do no setup adjustments. So, you see change the outside tires. Transition to the inside.
[14:18] Drop the car and go. That was one of the fastest ones. And the the team is very proud of that, and they they should be. That was That was That was a good one. Uh this one here, I will roll that too. So, in this one we're going to change four tires just like we did in the last one, but we're going to do two different
[14:34] setup adjustments. So, watch the outside rear tire changer change the tire, perform the adjustment, and then we're going to watch the rear tire changers again. They will perform the adjustment, which delays the launch of the car,
[14:50] and then away they go. Now, it might seem like a very short amount of time the difference between the last one and this one, but for us that could be several different positions that we lose in the race. Uh so, you can see the impact that it might have for us.
[15:05] And then, probably the fun one here. Uh if you were going to consider trying out for our pit team, and you should. We do have tryouts. Uh this is what you might see. So, here's a compilation of first-person views from a pit stop uh earlier in the season.
[15:21] So, we'll change the front tire, change to the rear tire, and away we go. It's really an incredible amount of
[15:37] coordination that it takes between all the athletes to get that done in in such a short time. It's It's very impressive. So, let's look at some of the real data from our pit stop tables. And remember those athletes that we just saw in the videos, they're used to using those videos and this data as part of
[15:53] their weekly coaching process. On the left side uh is a relation we actually discovered when we moved all of this into Data Bricks. Um sorry, I've had to hide the x-axis. I can't can't tell you all of my secrets. But on the uh left-hand side y-axis, we
[16:09] have total pit stop time. So, you can see there's a very clear frontier there where this particular variable becomes the limiting factor in the pit stop. And we were able to use that as a coaching point later on. And then on the right-hand side x-axis, we have the car's position relative to
[16:25] the wall. So, further to the right is further away from the wall. And the left-hand side y-axis, we have the fueler's transition time. So, the fueler takes the fuel from the wall over to the car and plugs it in. And you can see a nice illustration there of the
[16:41] pretty intuitive uh conclusion that the further they have to go, the longer it takes. And then a uh then our favorite quote from our pit department lead across the bottom there indicating that they really have done so much more since with their data since we've transitioned over to
[16:56] Data Bricks. It's been a a great result for the team and a great result for the data platform. But remember, we are doing this all after the race is over. We're taking that data from safety culture, we're taking that pit stop
[17:12] data, we're unifying that with our engineering and simulation data, and we're learning what we should have done in the race, but we don't have the ability to influence the result. Leading to the inevitable conclusion that we need to stream the data into our
[17:27] Databricks installation. So, for year two, we set ourselves the goal of streaming into Databricks to unlock that data-driven decision-making during the race so that we can influence the outcome, but it also is going to unlock a lot of
[17:43] new workflows for us that really let us increase the data volume that we address. So, we evaluated all of the common streaming options that were out there. There's obviously Kafka, industry-standard, very performant message bus,
[17:59] but for us that would have meant setting up additional infrastructure, possibly some training for our developers, and that didn't really align well with our goals for the platform. There's also all kinds of patterns out there where you can write Parquet directly to cloud storage, but you're developing a lot of things,
[18:15] you're controlling a lot of moving parts, and you still need a pipeline at the end of it to turn that into tables in Databricks. So then we were at this conference last year, and we heard about Zerobase. So, Zerobase promised to write all of this data for us to tables from an SDK.
[18:33] It sounded exactly like what we needed, but that presented a lot of risk for us since it was a brand new a brand new solution. So, we asked our very, very friendly Databricks solution architect how he would handle that problem, and I'll introduce Nick.
[18:53] Thanks, Chris. I'm I'm Nick Ragoneesi. I am the solutions architect on the working with Track House for about Yeah. Can you hear me? Can you hear me? Good? Okay. All right, cool. Um I've worked with Track House for about 18 months now. Uh I've also who have
[19:10] working on our sports team since we created it, so for about 3 years there. And so I'm just going to kind of walk you through what happened when Chris came to me with the idea of using Zero Bus, what that journey looks like. I think this can be a helpful framework for anyone really using Databricks. We
[19:26] come up with a lot of new features very frequently, so oftentimes you have to understand how these features fit into our platform and then how they're going to fit within your data stack. But the funny thing about learning these features as an employee at Databricks is oftentimes I'm learning about these
[19:43] features a month, a week, maybe even an hour before you learn about them at the summit. So oftentimes it's a bit of a scramble for me to figure out how is this going to help my customer succeed. So in this particular case, it started just with the ask, which was a little
[19:58] vague of hey, what is this Zero Bus? Can it help us? Can it sustain the greater than 1 million messages per second that we need to stream in, greater than 100 megabytes per second, and then eliminating the streaming infrastructure as well. As Chris had alluded to, they
[20:14] are a very talented team, but they are a small team. They're doing a lot with a little. What appeals to them in terms of the Databricks platform is our ability to manage a lot of the infrastructure for them, so they can focus on what they care about most, which is
[20:31] trophies and prize money, right? And then the final component of it was obviously just the core goal of landing the data directly into Unity Catalog. So Chris came to me with all of these requests, and with my less developed experience within NASCAR at the time, I
[20:48] have definitely learned since, all I really heard from him though was that he wanted to go fast. And I love that movie. I have learned that it is a bit of a undersell in terms of the amazing engineering achievements that happen
[21:04] every single day in NASCAR, uh but it still gives me a chuckle and I think uh everyone within the industry occasionally laughs and then sometimes gets frustrated that maybe that might be their public perception. So, after you kind of have the like okay, there's a question of a new piece
[21:20] of a platform and can it help uh customer, it comes back to the platform itself, right? And I imagine everyone who is at this conference has seen some version of this uh slide. I am not going to go through the whole thing. Uh it's already outdated as of 4 hours ago,
[21:36] which is just another part of working at Databricks, but the core thing that I always try to do with a new feature is well, let's start. Where does it fit within our platform, right? And that made it pretty easy of well, it's clearly within the Lake Flow section, right? Uh this is about uh ingestion,
[21:53] even more particularly in terms of how to get the data into Databricks. So, now we've kind of narrowed down, okay, it's in the ingestion side of the Lake Flow's Lake Flow piece of the Databricks platform. From there, it becomes a question of well, what does this feature look like
[22:09] on a management standpoint? Most of our features go from more managed connectors to very customized solutions, right? So, think about on the managed connector side for ingestion, if you have our Salesforce connector, for example, right? You just
[22:26] want to be able to point to a Salesforce instance and get that data into your lakehouse. You don't necessarily care about the details of how it gets there as long as it is relatively uh cost-efficient as well as time-efficient, right? So, you may offload a lot more of that to
[22:43] Databricks, allow us to manage that for you, so you can move on to other things. On the other side of the more customized solutions, you might get structured streaming, uh uh traditional Spark streaming in this case, right? So, uh that's where you would be managing all of the watermarks
[22:58] and checkpointing that would come within streaming. So, ZeroBus here falls a little bit in more of the middle ground, right? So, uh closer towards the Lake Flow declarative pipelines type of feature where there are some customizations available for you, but um a lot of it
[23:15] you do uh have to you do kind of offload that management to Databricks. And of course, it wouldn't be a Databricks presentation if there weren't some confusion with naming. Uh Lake Flow declarative pipelines is uh Spark declarative pipelines now in case there's people are
[23:31] asking about that component of it. So, now that we've kind of narrowed down, okay, we know where within the platform it fits, the question is, well, what problems does it solve? First for me, I have to understand what problems we're solving holistically within the industry, and then I can narrow down to
[23:48] how does this apply to problems that I'm solving for my customers, Trackhouse in this case. So, in order to understand that, I talked to our very talented product manager, Victoria Butka, who I don't know if she's here. Uh if she's not though, special shout-out to her. She
[24:04] was very helpful in this process. And when I went to her and the product and engineering team for Zero Bus, it started with the question of, okay, well, what problem is this solving? And when they were doing their market research, what they found is a lot of
[24:20] customers who were doing streaming had this challenge of they wanted to offload data quickly from the source, and most commonly they were solving it by adding a staging area like a message bus, right? And so, I think a lot of people have seen some version of this where in the case of
[24:37] Trackhouse, you're going to have producers in the form of um race control and all of the other applications they have to monitor as well as the race car and the sensors on the car itself. And in the traditional paradigm of streaming in a message bus, you then have the
[24:52] message bus, there's a bunch of topics, and then Spark streaming would subscribe to those topics, potentially do some analytics there, and then write it to the uh data lake, right? And so, when Victoria and the product team were coming up with Zero Bus, they found that frequently customers
[25:09] using that paradigm had solved the offloading data quickly problem, but now they've created some new problems. The two core new problems that they saw, one data duplication. Chris alluded to it. It's near and dear to my heart. I
[25:24] got my start as a data analyst who spent a lot of his days responding to the question, this person's report says that, this person's report says that, figure out why. And often times that came down to data duplication, right? Different ways of tracking things, data coming from
[25:40] different applications, somebody with a spreadsheet they've managed for seven years that they have a very bespoke way of doing things and no one else understands it. So, all that I could do to reduce data duplication and help the kind of versions of me out there who might be having these
[25:55] problems, that was always going to make me happy. From there, the other component is the increased arc architecture complexity. That's the other thing that was potentially becoming a problem with that solution. Again, this wasn't going that would have made a problem for Chris and team. They are a small team. They're
[26:11] trying to do a lot with the handful of engineers that they have. They don't necessarily want to manage an entire Kafka infrastructure. So, that is where the Zero Bus API was created. So, we have the API that solves that problem. You can write directly to the
[26:28] Unity Catalog through that Zero Bus ingest API, and you can skip that message bus component of it. The product is now generally available, which is great. It's fun to see again like this journey started a year ago when we were at this conference, and now we are generally available.
[26:45] And we are seeing some really awesome performance numbers. You can see delivering near real-time rights less than 5 seconds and high throughput as well. Um often times these kind of SLAs are a little bit of uh under promise and over deliver. I know for a fact that the Trackhouse team is seeing much better
[27:01] performance than this. Um and so yeah, like over the past year they have gone from being the early testers of this to now it is generally available, which is amazing. Uh so what their architecture now looks like instead of this before architecture
[27:17] where you'd have that message bus and the Spark streaming component, they can use Zero Bus ingest to get the data directly from the race car and write it to their data lake. Final piece of component for me just in summary, like what this looked like uh
[27:34] in terms of a timeline, which was fun. So might be a little small for y'all. I can't read it down here, but in uh July of '25 was when they were onboarded to the private preview. So this was very early stages. Uh there were no public documents. There was no marketing page
[27:49] about it. Uh there was no Slack channel for them to talk directly to the engineers. Um it was just an SDK with a private preview license and an ingestion URL that Vicki had issued by hand herself. I think this is even before broad adoption of cloud code, so Vicki
[28:04] even had to write the email herself to send it over, I imagine. From there uh in November of '25 was the first race day test. So we were actually up against time a little bit. It was the last race of the season for NASCAR, um
[28:20] but we were able to get it up and running successfully for that race, which was extremely exciting. After that, in February of '26, we had uh Daytona and the product became GA I think about 3 weeks after that. And you'll notice it's a very quick
[28:36] turnaround for NASCAR. This is uh you know, kudos to the Trackhouse team because the final race of the '25 season is in November and then they have to quickly turn around for February for the next season. And when you factor in all of the holidays and people might want to take some vacation, they really do not
[28:52] have a lot of time. So, it just uh really speaks to how much they're able to accomplish during the year with a very lean and efficient team. Um and so, at that race at Daytona, um we did have the product up and running. There were a couple of hiccups, which will happen
[29:07] anytime you have a preview feature. Um I was personally happy to learn that it was in fact a challenge on the track house software side. I don't think that makes Chris feel any better, um but, you know, occasionally it's it's great for me to just know, "Hey, the Databricks product was not the solve of this
[29:22] problem the cause of this problem." Because often times in my role it is learning how we might have caused issues for our customers. But, everything was resolved quickly, which is great. Uh and that took us to May of '26. And so, uh there's they're now fully in
[29:38] production and things are going great. And I can't read the exact quote. I think it was something like, "Performing really well." Which is about as glowing of a review as you're going to get from an engineer. So, that made me extremely happy there. Um and so, with all that being said, I'm
[29:54] going to pass it back to Chris and he will talk more details in terms of what this was like from his side. Thanks. Thank you, Nick. And I definitely did not authorize the Ricky Bobby joke, but that's okay. Um so, a reminder of our previous batch
[30:11] architecture. You can see here we have three steps and two copies of the data. And then using Zero Bus, that really reduces just as Nick's slides predicted. So, the graph now has two hops and only one copy of the data in cloud storage.
[30:27] So, reviewing that architecture is great. We don't have to write any pipelines to get our data into Databricks anymore. And we're paying only for the minimum possible storage. And again, doubling up on that storage cost was a bit of an issue for us with the previous architecture. It does require a place for you to run
[30:44] the ZeroBus SDK, so you do have to write an app, but we were already writing that app, and I really imagine that if any of you are considering ZeroBus as well, you have similar apps already. So, let's talk about some of the performance that we have achieved.
[31:01] We're sustaining that million messages a second, or over 100 megabytes a second, and we're doing that all with essentially zero back pressure at the ZeroBus app site. It certainly wasn't perfect the first time. Nick mentioned that that we did have our issues. Uh we did have to
[31:17] experiment a bit with the message sizes and the schemas to get those higher data rates to work, but it was definitely worth it, and we are very happy with that performance that we're seeing now. So, here's some actual data from earlier uh races this year. On the top, we have
[31:33] message counts aggregated per minute. I know we've been quoting per second, but it makes the graph a lot cleaner. Uh so, you can see the fluctuations in data rate there. Those are expected due to when the race is under yellow flag conditions and the cars are making less data or green flag conditions, and you see that full rate up and over a million
[31:51] messages a second. And then on the bottom, you see latency in time at the ZeroBus SDK app, and you can see for all practical purposes, that's essentially under 10 milliseconds the entire time.
[32:08] So, our experience with ZeroBus has been great so far. It's been super fast, and there's been zero infrastructure setup, which aligns well with our goals for the platform and our team. And then I will do one quick note, if any of you are considering using ZeroBus, somewhat counterintuitively, all
[32:23] permissions does not work. I had to learn this lesson very painfully and several times over. So, hopefully I just saved all of you a lot of time. It was the only gotcha uh that we hit, but we definitely did need to learn that lesson.
[32:42] So for us, Zero Bus has unlocked that real-time data-driven decision-making. We can adjust that pit strategy that we talked about, the car setup that we talked about, and do it all live during the races with data that is streaming in. And we're hoping that that's going to help us with those most important metrics again, the trophies and the
[32:58] prize money. So conclusion for us, Zero Bus has decreased our latency from days to essentially real-time. We've gone more than 10x in data volume that we're addressing, and we've done it all with no additional infrastructure, very
[33:14] little additional staff training, and that really allows our developers to focus on the data content and not the platform buildout. It's really allowing us to have the data platform that we need to win more races and to increase the value for our partners.
[33:30] So thanks to Nick, thanks to the entire Zero Bus and Databricks team. It's been a real pleasure. Thank you all for coming.

Learn more about the Databricks Data and AI platform.

The information provided herein is for general informational purposes only and may not reflect the most current product capabilities or configurations.