The feature store that refuses to pick a database

What it does

Feast is an open-source feature store that mediates between your existing data infrastructure and machine learning models. It keeps an offline store for historical batch data used in training, a low-latency online store for real-time inference, and a feature server to dish out pre-computed values. The aim is to let platform teams define features once and retrieve them consistently without rewriting pipelines every time someone swaps the underlying database.

The interesting bit

Its real defense against chaos is point-in-time correctness: it generates training datasets using temporal joins so future feature values do not leak backward into historical rows. That sounds like a narrow detail until you realize it is the exact bug that silently invalidates models in hand-rolled ETL. Feast also abstracts retrieval so the same feature definitions work across batch, realtime, and streaming pipelines.

Key highlights

• Broad backend support, from Snowflake and BigQuery to DuckDB, Redis, DynamoDB, Cassandra, and a growing list of vector stores such as Qdrant and Milvus.
• Point-in-time feature generation to prevent training-serving skew and data leakage.
• Incremental or full materialization of offline data into the online store.
• Alpha vector search for NLP workloads, with an RFC for deeper native integration.
• An experimental web UI for browsing registered feature definitions.

Caveats

• The built-in web UI is explicitly marked experimental.
• Vector search is in alpha, and enhanced NLP SDK support is still on the roadmap.
• The README is auto-generated from a Jinja2 template, so documentation freshness may depend on the render pipeline.

Verdict

ML platform teams managing features across multiple data systems—and anyone who has debugged a temporal join at 2 a.m.—should evaluate Feast. If your entire pipeline fits comfortably in a single DuckDB file, this is likely overkill.