bsport builds an agent-ready data stack with SDP

bsport provides an all-in-one management and marketing platform for boutique fitness businesses, helping studios manage everything from scheduling and payments to customer relationships and day-to-day operations. Behind those experiences, bsport’s data team brings together nearly 20 data sources to power internal decision-making, customer-facing analytics and AI-powered experiences.

When Adrien Marteau joined bsport as Head of Data, the company had outgrown its legacy data architecture. Analytical transformations ran on Postgres through an internally developed SQL framework, while ingestion relied heavily on custom Python integrations and orchestration through Airflow. Connecting new sources often meant writing bespoke code, transformation involved large chains of SQL tasks, and documentation was largely manual.

Marteau set out to build a more scalable, reliable foundation on Databricks - one that could meet bsport’s immediate modernization needs while reducing the custom infrastructure its data team would have to maintain as its use of data and AI evolved.

Apache Spark™ Declarative Pipelines (SDP) became an important part of that transition. Rather than requiring bsport to redesign every existing workflow before it could migrate, SDP gave the team a declarative path for bringing SQL workloads onto Databricks and an expanding set of patterns for ingestion, change data capture and streaming.

Accelerating the move from custom infrastructure to Databricks

Rather than making its platform migration dependent on a wholesale rewrite, bsport used SDP to quickly bring existing SQL transformations onto Databricks. The team didn't have to redesign its entire dependency graph upfront: it could establish parity with its legacy environment, take advantage of Databricks scalability, and then progressively improve its architecture.

That sequencing allowed bsport to modernize while its existing operations continued running. Once workloads were on Databricks, the team could turn its attention to stronger governance, better-defined silver and gold layers, and more intentional data modeling rather than trying to solve every architectural problem during the initial migration.

For a team where nobody had previously worked directly with Databricks, SDP also provided an accessible starting point. Scalability, dependency management and lineage came with the framework rather than requiring the team to build and maintain those capabilities itself.

“Once that was done, it was very easy for our team to just deploy, test, evaluate and put the pipeline into production,” Marteau said.

The entire end-to-end modernization took just months with a four-person team - even as bsport changed Databricks environments mid-migration and introduced new capabilities along the way.

Standardizing ingestion with declarative CDC

As bsport’s architecture evolved, the team began applying SDP to workloads where declarative patterns could eliminate significant operational complexity - particularly ingestion and change data capture.

Previously, connecting systems often meant writing custom Python against individual APIs, loading the data, and coordinating large chains of SQL transformations. The result was substantial custom code and internally maintained framework logic.

Today, bsport is standardizing more of its ingestion architecture around reusable declarative patterns. With AUTO CDC, the team can process and update tables independently, so a delay or failure in one data source doesn’t hold up the rest of the pipeline. That gives bsport fresher data, better failure isolation and less orchestration complexity — without requiring the team to build and maintain custom CDC logic.

The same declarative approach simplifies more complex change-data patterns. When teams need to understand how records have changed over time, for example, bsport uses AUTO CDC to implement SCD Type 2 directly in SQL - a setup Marteau described as “super easy” and “very simple.”

SDP is also helping bsport expand into Kafka-based streaming sources. The team can consume streaming data into Databricks and materialize it into lower-latency tables while applying CDC patterns downstream.

Together, these patterns give bsport a more standardized way to handle batch and streaming ingestion, CDC and historical change tracking without building a separate custom framework for each requirement.

Cutting data lag by 10x

The modernization has dramatically changed how quickly bsport can make data available.

Under the legacy architecture, some data arrived with more than 24 hours of lag - sometimes leaving teams or customers working with data that was one or two days old. Long-running tasks could also fail or retry hours into execution, delaying everything that depended on them.

Today, bsport’s data warehouse analytics are fully materialized within an hour or two. In the worst case, Marteau estimates data availability has improved by roughly 10x.

Reliability has improved alongside freshness. Complex analytical queries that previously timed out can now complete successfully, and the team can scale compute to match individual workloads rather than being constrained by shared resources.

“Now if you ask a question, you get an answer right away,” Marteau said. “Our data is way more accessible.”

The migration has also reduced infrastructure costs. Marteau estimates that moving internal reporting workloads from the legacy Postgres environment toDatabricks compute and lower cost storage reduced infrastructure costs by approximately 33%.

Shifting from data mechanics to customer value

For bsport, the impact goes beyond faster pipelines.

Previously, the data team spent significant time dealing with infrastructure limitations, failed or retried jobs, timeouts and questions about whether reporting data was current and trustworthy. With a more reliable foundation, the team has been able to redirect its attention toward data modeling, governance, documentation and KPI validation. Marteau said the previous stakeholder distrust around reporting numbers has “disappeared.”

That foundation has also enabled bsport to build a more reliable client reporting suite with forecasting and hourly updates, helping teams respond more quickly to customer requests rather than waiting for daily data refreshes.

Instead of spending as much time keeping custom infrastructure running, bsport’s data team can increasingly focus on structuring trustworthy data and turning it into insights for customers and internal stakeholders.

“It helps us shift our responsibility from ingesting and transforming to providing insight, providing value directly to our stakeholders and answering their questions,” Marteau said.

Building the foundation for agentic data engineering

As bsport brings AI into more of its development and analytics workflows, the standardization created through its modernization is taking on new importance. The team is already using Genie and Databricks development tooling to accelerate development, investigate and debug data, and make technical information more accessible.

For Marteau, keeping those experiences close to governed data is intentional. His vision is a platform where data can move from ingestion and transformation through consumption without unnecessary handoffs, while maintaining governance as more people and AI-powered tools interact with it.

That makes the underlying data engineering foundation increasingly important. Instead of agents and engineers having to navigate bespoke scripts and internally maintained frameworks, bsport is building around more standardized, declarative patterns backed by governed data and lineage.

SDP provides those patterns across use cases including SQL transformations, materialized views, streaming tables and AUTO CDC, while Databricks provides the broader environment for governing and consuming the resulting data.

For bsport, the result is more than a modernized data stack. It is a simpler, more standardized foundation designed to help its data team - and the increasingly agentic tooling working with it - spend less time managing the mechanics of data engineering and more time turning trusted data into value.