Turo is the world’s largest car-sharing marketplace, operating across more than 300,000 host-owned vehicles across the US, Canada, UK, France, and Australia. At this scale, machine learning systems are foundational infrastructure. They determine how guests discover cars, how owners price trips, and how trust is enforced across the marketplace. In a two-sided marketplace, small changes in relevance, pricing, or trust compound quickly. Those gains show up as higher liquidity, stronger conversion, and increased revenue.

Turo applies machine learning across three critical areas: ranking vehicles in search results, providing dynamic pricing recommendations for hosts, and assessing risk. These systems span both batch and latency-sensitive workloads and operate at different points in the funnel, from high-traffic search requests to downstream risk decisions. Supporting this range of use cases requires a compute-first feature store that handles both batch and real-time feature computation, with low-latency serving in production. Slow iteration or inconsistent features don’t just hurt models. They slow feedback loops between supply and demand.

Operating at global scale with hundreds of thousands of active vehicles, Turo sees outsized impact from even small improvements in search relevance or pricing accuracy.

Search, pricing, and risk all have very different requirements, but they all depend on features being predictable and available in production.

Darryl Vo Engineering Manager

Before Chalk, Turo did not have a unified feature store for production feature delivery.

Feature data lived in multiple places. Machine learning engineers often had to comb through production databases to find viable data sources, then craft Airflow jobs and bulky pipelines to make feature data available for online use cases. Feature definitions and model logic were scattered across repositories and services, making it difficult to treat features as shared, reusable production assets.

As a result, feature delivery became a constraint on how quickly Turo could adapt pricing recommendations, improve search relevance, or refine risk decisions as marketplace dynamics changed.

Each new feature followed a different path to production. Shipping changes meant locating the right data, extending bespoke pipelines, and coordinating with multiple teams to provision infrastructure. The bottleneck wasn’t modeling. It was operationalizing features fast enough to keep pace with the marketplace.

For a marketplace business, this friction directly affected how quickly Turo could learn from user behavior and improve liquidity, conversion, and trust across the platform.

We had all the pieces of an ML platform, but no single, consistent way to productionize features.

Darryl Vo Engineering Manager

Turo adopted Chalk to create a single, repeatable path for production feature delivery, using Chalk as its centralized feature store, owned by the ML engineering team and deployed in Turo’s own cloud.

With Chalk, feature definitions live in one place and follow consistent patterns across different models. Features are defined around shared entities and computed through resolvers that encode how data is fetched, joined, or refreshed in production. ML engineers, MLOps, and data scientists can all directly define and iterate on features in Chalk, using the same abstractions and workflows.

Chalk absorbed much of the feature-related data engineering work that previously required custom pipelines or cross-team coordination. The team developed standard workflows that cover roughly 80 percent of feature delivery needs, allowing feature development to happen collaboratively while the ML engineering team owns production ingestion, serving, and APIs.

This allowed the ML engineering team to own feature delivery end-to-end, without relying on data engineering teams whose priorities were focused primarily on analytics rather than ML.

At a platform level, this enables Turo to standardize on a small set of repeatable primitives:

• Centralized, entity-based feature definitions shared across models
• Resolvers that define how features are computed, ingested, or refreshed
• An online feature store optimized for low-latency production access
• Self-serve workflows owned by the ML engineering team

@features(max_staleness="10d")
class InternalAutomaticPricingMinMax:
    id: Primary[str]
    min_max: list[MinMax]

def create_ap_min_max_resolver(config: SQLResolverConfig) -> None:
    sql = load_sql_template("automatic_pricing_internal_min_max.sql")

    for version, table_name in TABLE_MAP:
        if config.environment == "staging":
            cron = "0 20 * * 0"
        else:
            cron = None
        make_sql_file_resolver(
            name=f"get_{config.environment}_{version}_ap_internal_minmax",
            kind="offline",
            environment=config.environment,
            sql=sql.format(
                default_db_name=config.default_db_name,
                version=version,
                table_name=table_name,
            ),
            source=redshift,
            resolves=InternalAutomaticPricingMinMax,
            tags=f"ap_internal_minmax_{version}",
            cron=cron,
        )

Above is an example of a resolver loading data from a SQL table on a daily schedule. Before Chalk, moving data from analytics or data science into Turo’s production microservices required custom pipelines and coordination across teams. With Chalk, teams can populate a SQL table and trigger offline feature computation, making the data available to production services through a standardized feature interface, typically within a day.

This shift reduced dependency on platform and data teams for most feature work. It also made production practices more consistent as the number of models and features increased.

Chalk’s compute-first architecture allowed the team to define feature logic once and rely on Chalk to handle execution and serving, rather than maintaining bespoke pipelines per model.

Chalk let us turn feature delivery into a self-serve workflow. We stopped waiting on other teams for every new feature and started shipping on our own cadence.

Darryl Vo Engineering Manager

Turo runs Chalk in its AWS cloud environment. The ML engineering team manages the platform day to day and works with the platform team for deeper infrastructure support when needed.

Data ingestion patterns

Most production features follow a SQL-driven workflow:

• Data scientists or MLOps workflows generate tables using Airflow
• Airflow triggers Chalk offline feature computation via SQL and Python resolvers
• Chalk computes and loads features into the online store
• Services request features at inference time through internal APIs

This design positions Chalk as a feature engine focused on predictable, low-latency serving in production.

Models and latency

Chalk supports several core model families at Turo:

• Pricing models, which are largely batch-oriented and have the highest feature volume
• Vehicle search models, which are latency-sensitive and operate high in the funnel
• Risk models, which tend to be lighter-weight and run later in the flow

Based on their integration, Chalk provides consistent response times that allow engineers to design systems around expected feature retrieval latency.

For our high-funnel search workloads, predictability matters.

Darryl Vo Engineering Manager

Standardizing feature delivery on Chalk improved both iteration speed and operational clarity.

As model complexity increased, Chalk scaled with it. The platform absorbed more load as teams iterated faster, rather than becoming a bottleneck.

As our models get more complex, Chalk gets used more, not less.

Darryl Vo Engineering Manager

Turo is extending its feature platform toward streaming, using Chalk as the foundation for both batch and real-time feature delivery. As new models are introduced, feature work now defaults to Chalk first, with streaming ingestion becoming a natural extension of the same feature definitions and serving patterns already in production.

This approach allows the ML team to pursue more advanced real-time use cases without reintroducing data engineering bottlenecks or disrupting existing production workflows.

Chalk has shifted feature engineering at Turo from a coordination-heavy bottleneck into a scalable platform capability. The result is faster iteration today and a durable foundation for streaming and real-time ML tomorrow.