Building a soccer coaching app on Databricks

Building a soccer coaching app on Databricks | Databricks Blog Skip to main content

Summary

Coach’s Corner is a Databricks App that turns 25 fps match tracking data into a sub-second 2D/3D tactical bench with replays, event analytics, a scout chat, and an opponent-dossier agent.

It runs on one platform, powered by Databricks end-to-end. Lakeflow pipelines refine 51 million rows through bronze, silver, and gold, DBSQL queries them in 1 to 3 seconds, and Lakebase serves them to the app in milliseconds.

The AI layer is grounded in the same governed data, including a Genie space to answer scouting questions, Vector Search to find similar players, and an agentic dossier that calls an LLM served through the Unity AI Gateway, with every step traced in MLflow.

Tracking data is now the richest signal in sport, but the real gap is turning the data into something a coach can actually use. A modern match is captured at 25 frames per second (fps) from 19 separate feeds: every player, the ball, and every event, many times a second. For one tournament, that is 339 matches and 51 million rows of tracking data. Yet almost none of it is usable by the person who needs it most. A coach on the bench cannot read a 51-million-row table. Coach's Corner closes that gap, entirely on one platform. The challenge is not just scale, but timing and cognition. Coaches make decisions in seconds, not minutes, and traditional analytics workflows assume the opposite: batch processing, offline dashboards, and post-match review. Even when insights exist, they are buried behind tooling that requires an analyst to interpret and relay them. This creates a structural bottleneck in which the data is rich, and the models are sophisticated, but the decision-maker is effectively blind at the moment that matters. Meet Coach’s Corner, “La Pizarra” La Pizarra (“the chalkboard”) is a national-team technical bench that runs as a Databricks App. A coach picks a match and replays it in 2D or 3D, swinging the camera from a broadcast angle to a top-down tactical view and scrubbing at up to 8x speed. Layered on the replay are the analytics that matter: shot and xG maps, pass networks, heatmaps, set pieces, team shape, pitch control, ball trails, and player paths. Integrated with the replay features are several advanced tools: a comprehensive standings view, event-driven analytics, a unique Scout style-signature for evaluating any team, and a Tactical Agent capable of generating on-demand dossiers for upcoming opponents. The bench view places the entire match in the coach's hands, enabling seamless transitions between broadcast and tactical top-down perspectives. With 8x scrubbing and automated overlays for passing lanes and heatmaps, tactical elements like pitch control and team shape become tangible patterns on the field rather than distant metrics.

The technical foundation of Coach's Corner was dictated by a single guiding principle: the interface had to function as an extension of a coach's natural instinct rather than a complex analytical instrument. This required a design that reduced interaction overhead, favored spatial context over traditional graphing, and presented every metric as a dynamic element of the game. By anchoring insights directly to the field of play, the application eliminates the need for manual data interpretation and delivers critical analytics precisely when they are most relevant. One platform, every hop The core data engineering happens under the hood. Raw tracking feeds land as NDJSON in a Unity Catalog Volume, where Auto Loader ingests them incrementally using the Lakeflow Connect pattern. From there, Spark Declarative Pipelines process the data through bronze, silver, and gold tiers, running entirely serverless on Photon with 46 named data quality expectations enforced. The final gold tables, including a 51-million-row frame table, leverage liquid clustering to enable 1-3-second query response times via DBSQL running on a small warehouse. By consolidating all volumes, tables, models, and indexes into a single Unity Catalog, the architecture eliminates vendor glue code and secondary governance systems. The architecture deliberately avoided fragmentation by resisting the shift toward specialized microservices. Rather than splitting ingestion, transformation, serving, and AI orchestration into isolated, locally optimized stacks, the system stayed unified on a single platform. Keeping everything inside Databricks traded some theoretical flexibility for operational coherence: a single governance layer, consistent lineage, and no impedance mismatch between systems. This becomes especially important when AI is introduced, because the cost of ungoverned or inconsistent data compounds quickly. Spark Declarative Pipelines redefine reliability by shifting from an imperative model to an explicit one. Instead of relying on rigid jobs with embedded assumptions, the system treats data quality as a first-class concern by enforcing formal expectations. This suite of 46 expectations serves a dual purpose: it safeguards the pipeline in real-time and establishes data “correctness” for downstream consumers, including replay, analytics, and AI agents.. The diagram below is the architecture powering the bench view. At the top sit the experiences a coach touches: replay, analysis, scout, standings, and agents. In the middle, each of those experiences is backed by governed layers: Unity Catalog for data and models, Lakehouse and Lakebase for analytical and transactional serving, and Vector Search for similarity. At the bottom sits the raw reality it all starts from: 25 fps tracking feeds, match events, player profiles, and lineups, all landing into an open lake.

Optimized serving paths for speed and scale To ensure peak performance, the application utilizes two distinct architectural paths for data retrieval. High-speed tracking replays are powered by Lakebase, which synchronizes gold tables to Postgres to enable millisecond-level windowed frame reads. By allowing the browser clock to pull only essential frames rather than scanning entire matches, the system maintains a fluid interactive experience. Conversely, heavy event analytics are routed through the Statement Execution API to the SQL warehouse, keeping intensive computational queries separate from the responsive 3D replay. This deliberate bifurcation between Lakebase and DBSQL addresses differing access patterns rather than just raw speed....