Sports Tech's Quiet Data Shift: Self-Hosted Dashboards and Agents Doing the Queries

Most of the noise around sports technology in 2026 comes from market forecasts and sponsorship announcements. The actual tooling is quieter, and it tells a more specific story. Analytics teams are moving their dashboards off vendor clouds and giving AI agents direct database access. Then they argue about the bill.

Two open source releases from September sketch the first half of that shift. Both are self-hosted. Both assume the data already exists somewhere. Neither is a sports product in the way a fan app is.

They are the plumbing underneath the scoreboards.

GA4 dashboards you host yourself

On 8 September, a software consultancy called Adaca published Adaca Analytics on GitHub under the MIT licence. The project is a self-hosted dashboard layer for Google Analytics 4 that runs on Cloudflare Workers, according to its repository. The mechanics matter more than the pitch. Daily rollups come either from the GA4 Data API or from a BigQuery export, and they land in a D1 database the operator owns, the README says. Realtime data stays on Google's side. Dashboards are assembled from configurable widgets on a grid. Six dashboards ship out of the box, and a four-step builder handles custom ones.

The repository claims every number drills through. Sources, pages and countries each get detail pages with their own trend and breakdowns, precomputed so they load in one round trip.

There is one filter per dashboard, saved segments, and read-only share links that can pin a filter. Comparison runs against the previous period, last year, or any window, with hourly detail for the current day and a live visitor count. Weekly and monthly summaries plus traffic alerts go out by email or Slack. Setup is deliberately unglamorous. An operator creates a Google service account with Viewer access on the GA4 property, downloads its JSON key, and presses Deploy to Cloudflare. That forks the repository, provisions D1 and KV, asks for the key, and deploys the Worker with its cron. Cloudflare Access or built-in Basic Auth goes in front, because there is no sign-in. Then the first backfill runs while you watch.

For sports organisations running several properties across leagues, teams or regional sites, the pitch is control: a D1 database you own, no per-seat analytics contract, and BigQuery export support for anyone already piping GA4 into a warehouse.

The catch is operational. Self-hosting means you own the cron, the auth layer and the migrations.

Analytics middleware inside the app

Five days later, on 13 September, a separate project called Plainoldanalytics appeared on GitHub. It is a bolt-on web analytics library for Go applications. Its README describes it as similar in spirit to Umami, Plausible or PostHog, but embedded in your app rather than run beside it. The core package is storage-agnostic: importing it never pulls in a backend. Developers pick a storage package, such as a memory store or DuckDB, and one constructor call gives them both a working Storage and the Analytics wiring. Traffic flushes to disk roughly once a second, and a Close call on shutdown flushes anything still buffered.

The library sets key and value properties on each request, which the built-in dashboard can filter on. It also special-cases a user property, so all traffic tied to one user shows up together.

Routes with path parameters are recorded as parameters by default, with a UseRequestPath wrapper available when the literal route matters. There is an Exclude call for routes that should not be logged at all, plus adapters for gin and chi, and an optional browser session recording script. For a club or federation running ticketing, membership or content services in Go, this is the difference between a third-party script on every page and a middleware line in the router. Neither project is a sports analytics platform. Both remove a vendor from the path between the event and the number.

The architecture argument: who runs the query

The harder question sits above the tooling, and Starburst tackled it in a blog post on 11 September titled "An Analysis of Two Architectures for Agentic Data Analysis". The premise: agents are increasingly supplementing or replacing human data analysis, taking on questions with follow-up questions and multiple rounds of analysis across one or more datasets. Starburst's worked example is a grocery store asking whether last week's egg promotion was profitable. Answering it means knowing whether the sale drew customers who would not otherwise have come, whether new customers returned, what else was in the same basket, and how profitable those items are. Sports questions look the same shape: did the streaming push bring new subscribers, did they stay, what else did they buy.

The post lays out options for feeding data to an agent. Option 0 is extracting raw data and sending it over.

Starburst calls that impractical outside unusual circumstances, because agents that charge per data item can make terabytes prohibitively expensive.

These disadvantages of option 0 reduce its practicality to the point where it is not a good option in practice. This is why I'm calling it "option 0" — it is not something that I would recommend outside of specific unusual circumstances.

Option 1 is giving the agent direct access to the database and letting it write its own SQL, iterating until it reaches a conclusion. The database engine handles query planning; the agent merely oversees. Starburst notes the literature flags a real risk here: agents can be far more demanding than humans and can overwhelm a system with speculative queries as they refine their focus. The post's conclusion is a division of labour. It argues it will be a while before agents process terabytes of structured data at the same level of optimisation as elite database systems built on decades of research. Until then, the engine keeps the heavy lifting.

What it adds up to

Read together, the three pieces point the same direction. The collection layer is being embedded in the application. The presentation layer is being moved onto infrastructure the operator controls. And the analysis layer is being handed to agents that query databases directly rather than receiving dumps. None of this appears in the headline market forecasts. It is the part of sports technology that decides whether the number on the screen is right, how fast it arrives, and who pays for the tokens.