Feature Store

The Feature Store is where you define the features your models use, keep their values fresh, and serve them consistently for both training and live inference. It solves the two problems that quietly break most ML projects: the same feature being computed differently in training than in production (training/serving skew), and training data that accidentally includes information from the future (label leakage).

Open it from MLOps > Feature Store. The cards count your stores; the list shows each store's Name, Status (Ready or Disabled), Online Serving (Online or Offline only), its Backends and when it was Updated. Search by name. Feature Catalog finds features across stores, and Create Feature Store adds one.

Concepts

A feature store is built from four kinds of objects:

• Entity: the thing features describe, identified by one or more join keys. For example, a driver entity keyed by driver_id.
• Feature view: a named group of features for an entity, with a schema and a data source. A view is immutable per version: an additive change (a new nullable column) reuses the version, while a breaking change creates a new version so existing consumers keep resolving what they were built against.
• Feature service: the model-facing contract. A service pins a specific set of features (at specific view versions) so a model always trains and serves against exactly the same definition.
• Materialization: the scheduled refresh that moves feature values from the offline store into the online store so they can be served with low latency.

Storage

A feature store keeps its definitions in the platform and its feature values in storage you select when you create it:

• Offline store (required): a durable Postgres add-on or Postgres data source. It holds the full history of feature values and is the system of record for point-in-time training data.
• Online store (optional): a Redis add-on or Redis data source. It holds the latest value per entity for low-latency serving. Enable it only when you need real-time features, online serving, or windowed aggregations; a store without it is training-only.

You choose these from your available add-ons and data sources when creating the store, the same way every other feature on the platform selects services. If you do not have a suitable add-on yet, create one first from Add-ons.

Creating a feature store

1. Go to MLOps > Feature Store and click Create Feature Store.
2. Give it a name (lowercase letters, numbers, and underscores) and an optional description.
3. Select the offline Postgres add-on or data source.
4. To serve features in real time, turn on online serving and select the Redis add-on or data source.
5. Click Create Feature Store. The store opens to its details page.

A new store is private to you. To share it, open its Permissions tab: share it with specific users, or allow all users in your organization. Someone a store is shared with for use sees its definitions and data read-only; only its owner and its editors change it.

Deleting a store, disabling it, or turning off online serving is blocked while a deployed model resolves online features from it. The platform tells you which models are using it so you can unbind them first.

A store's page

Open a store to see its offline store (Postgres), its online serving (Redis, or Offline only), its status and when it was updated, with Edit (its description and online serving) and its tabs:

Tab	Shows
Feature Views	Each view with its version, mode, features, entities, freshness, data on record and status, with Delete
Feature Services	Each service with its version, features, the Models trained on it and when it was updated, with Delete
Entities	Each entity with its join keys, value type and description, with Delete
Monitoring	For each active view: its freshness, Data on record, source ingestion, materialization (Materialized through) and the last error
Permissions	Who the store is shared with

In this section

• Defining features: entities, batch, streaming and on-demand feature views, and feature services, in the UI or with the SDK.
• Views, services and the catalog: a view's and a service's page, versions, and finding features to reuse.
• Ingesting and serving: writing and materializing values, online serving, and point-in-time training data.
• Models and features: training an AutoML model on a feature service, and serving a model with live features.

Access and sharing

Feature stores are owned by the user who creates them and follow the same sharing model as apps and other library items: keep a store private, share it with specific users, or make it readable across your organization. Every read and write is authorized against your access to the store, so discovering a store never implies permission to use it.