Shopify chose Feast because it could connect to Shopify's existing offline and online stores without owning the storage layer.
2
Shopify put a thin internal SDK and a monorepo around Feast so teams could reuse features while Shopify controlled naming, validation, and migrations.
3
Skyscanner's Kaleidoscope grew from a machine learning feature store into a shared system for machine learning and marketing, with GDPR rules and versioned data shared across both groups.
Summary
This reading group did not discuss a paper or book chapter; Matt Delacour and Mike Moran presented how Shopify and Skyscanner built feature store systems. Delacour explains why Shopify chose Feast over a managed service or a fully in-house system. Feast gave Shopify a common API while allowing it to keep BigQuery, Trino, and its own key-value store. Shopify added an internal SDK and used a monorepo to encourage reuse and control standards. Feature engineering stayed outside the feature store, in dbt and PySpark pipelines. Moran describes Kaleidoscope, which began as tables in an AWS database for machine learning and later became a shared system for marketing use cases. Its SDK can create schemas from dataframes, while its versioning model allows old and new versions of an attribute to coexist. Kaleidoscope also applies GDPR rules across both user groups. Both speakers describe slow-moving data and the boundaries between feature generation, storage, serving, and downstream use as unresolved design choices.
Shopify needed scale across offline training and online inference
Matt Delacour says Shopify had millions of merchants generating large amounts of data. Its first feature store use case involved only a small number of features, but those features covered billions of rows. The system therefore had to scale for offline training and batch prediction as well as online inference. The choice was between a managed service, a fully in-house system, and an open-source project such as Feast. Managed services could reduce infrastructure work, while an in-house system required a larger team and could drift from community practices.
Feast let Shopify keep control of its storage systems
Shopify chose Feast because its offline and online stores were separate from the Feast library. Shopify used BigQuery and Trino for offline data, and it created a community Trino offline-store plugin. For online serving, Shopify connected Feast to its own private key-value store rather than adopting Redis or DynamoDB. Delacour says this plug-and-play design was important because Shopify did not want the feature store to own data storage or impose infrastructure on latency-sensitive systems.
Shopify users interact with an internal library that depends on Feast. The library exposes Feast APIs while adding Shopify-specific validation, naming rules, and other conventions. Delacour says the team deliberately kept the layer thin. Too much abstraction would remove the reason to use Feast, while too little would force every user to handle future Feast migrations and breaking changes. Shopify could make a quick internal change, then report the issue or contribution back to the open-source project.
The monorepo was chosen to make feature reuse visible
Shopify considered separate repositories where each user group would own its feature code, but chose a monorepo. The team wanted teams to see existing entities and features before creating new ones. The repository contains entities such as users, drivers, products, and customers, along with feature views and feature services. A feature service can define a named set of features for a model version, which makes it possible to fetch different sets for experiments. Delacour notes that there is no universal answer, since other companies use a multi-repository approach.
Shopify kept feature engineering outside the feature store
In response to a question about transformations and reuse, Delacour separates feature engineering from the feature store project. Shopify uses dbt and PySpark for batch transformations, along with streaming tools. The platform team provides loaders and conventions so data reaches the offline and online stores in the expected format. Feast then describes where the data lives and fetches it for users. The feature store team helps standardize the handoff, but does not own the engineering work that creates the features.
Kaleidoscope expanded from machine learning into marketing
Mike Moran describes Kaleidoscope as a system that grew from Skyscanner's machine relevance effort. Its first version was a set of database tables in AWS because available feature store tools were not mature enough for Skyscanner's needs. Marketing later needed data while moving between vendors, and the company reused Kaleidoscope to publish data to marketing systems. Marketing and machine learning became its two main user groups. An attribute created for a destination recommendation model was later reused for marketing targeting.
Skyscanner used an SDK to make publishing data simple
Kaleidoscope takes a dataframe from a notebook, creates a schema, and publishes it through an SDK. Moran says the aim is to let someone move from an idea to production within about an hour or a day. The system supports reuse because an attribute created for one team can later be used by another. Moran also describes a review step: publishing can create a pull request that must be approved, which gives the team a chance to spot a duplicate or ask the producer to coordinate with existing users.
Kaleidoscope handles change through versions and breaking-change checks
Kaleidoscope allows two versions of an attribute to exist at the same time. It does not automatically notify every downstream user when a new version appears. Instead, data scientists and marketers can discuss the change while Kaleidoscope provides the mechanism for both versions to run. The SDK permits additive changes, such as adding a component, but blocks breaking schema changes unless the producer creates a new version. Older data remains readable when new nullable components are added.
Both systems leave freshness and processing boundaries unsettled
Kaleidoscope originally favored large amounts of slow-moving data and usually updated it once a day. Machine learning and marketing now need fresher data. Moran also describes trade-offs between Spark for batch processing, online systems, pandas conversions, and feature store logic. Delacour recommends separating pipeline stages so feature retrieval, materialization, preprocessing, and training can use tools suited to each task. Both speakers describe the boundary between generated data, stored features, and online serving as an area where a simpler shared approach could still help.
"We've adopted more of an SDK approach where if you take a dataframe in a notebook and you publish that to Kaleidoscope, we will automatically create a schema."Mike Moran31:37
Who should watch
You are choosing between a managed feature store, an open-source project, and an internal system, and need to understand the trade-offs from two large companies.
Your teams share data between machine learning and marketing, but need separate versions, approval checks, and privacy rules.
You are designing the boundary between feature engineering pipelines, offline storage, online serving, and the SDK used by data scientists.
