Feast Assess
Overview
Feast is the leading open feature store abstraction for offline and online feature serving across warehouses and Redis-class stores (Feast).
Assess when ML and agent features must be consistent between training and serving. Tecton, acquired by Databricks in 2025, targets managed real-time enterprise SLAs; Feast wins for OSS control (Databricks on Tecton).
Adoption Signals
- Active release cadence: v0.62 through v0.66 shipped between April and August 2026, adding Oracle, Ray, and MongoDB offline stores, Aerospike and ScyllaDB online stores, an Apache Flink compute engine, and data quality monitoring (Feast releases).
- Named users on the project site include Robinhood, NVIDIA, Discord, Cloudflare, Walmart, Shopify, Capital One, Expedia, HelloFresh, and Adyen; the site cites 293 contributors and 12M+ downloads (checked September 2026), and the repository has about 7.3k GitHub stars (Feast, Feast GitHub).
- Red Hat integrated Feast as the feature store in OpenShift AI 2.20 (technology preview, May 2025), and a Red Hat engineer is a Feast maintainer (Red Hat blog).
- Canonical launched Charmed Feast in July 2025 as a production-grade distribution that runs alongside Charmed Kubeflow, with up to 10 years of security maintenance (Canonical).
- Governance broadened beyond Tecton: in 2024 maintainers from Affirm, Red Hat, and J.P. Morgan were added with a stated goal of a 1.0 release (The Future of Feast), and Feast joined the PyTorch Ecosystem in January 2026 (Feast blog).
Risks
- Insecure defaults and server CVEs. CVE-2026-23537 (CVSS 9.1) allowed unauthenticated arbitrary JSON file writes through the feature server in all versions before 0.59.0 (Mend), and CVE-2026-18941 covers the no_auth default in the SDK and operator, which left feature, registry, and offline server endpoints unauthenticated and enabled remote code execution through malicious UDFs and cross-tenant reads (CVSS 7.7) (OpenCVE). Current docs state that no_auth is for local development only (Feast auth docs).
- Pre-1.0 churn. The 1.0 release announced as a goal in 2024 has not shipped; minor releases arrive roughly monthly and regularly change registry and feature-view behavior (Feast releases).
- You still own the pipelines. Feast is explicitly not an ETL system, orchestrator, or database (Feast docs); streaming features, backfills, and materialization schedules have to be built and run with other tools.
- Uneven backend maturity. Only the Dask, BigQuery, Snowflake, and Redshift offline stores are core; the PostgreSQL, Spark, Trino, and Ray stores are community contributions that the docs say are not guaranteed to be stable or feature-complete (Offline stores). Test the exact store combination you plan to run.
- Alternative consolidation. With Tecton inside Databricks, Databricks shops may get feature serving as part of their platform, which changes the build-versus-buy comparison for Feast (Databricks on Tecton).
Pros & Cons
Advantages
- Feast is Apache-2.0 licensed and vendor-neutral, having entered the Linux Foundation for AI in 2020, with maintainers from Red Hat, Affirm, and J.P. Morgan joining alongside long-time lead contributor Tecton.
- It sits on storage teams already run instead of adding a new database: the current release supports offline stores such as Snowflake, BigQuery, Spark, Trino, and DuckDB and online stores such as Redis, DynamoDB, Postgres, and Cassandra.
- Enterprise distributions exist for teams that need a support contract, with Feast built into Red Hat OpenShift AI and Canonical shipping Charmed Feast with up to 10 years of security maintenance.
Disadvantages
- Feast is still pre-1.0 (v0.66 in August 2026) with near-monthly minor releases, so upgrades need regression tests for registry, materialization, and serving behavior.
- Its servers had serious 2026 vulnerabilities, including an unauthenticated arbitrary file write (CVSS 9.1) fixed in 0.59 and an insecure no_auth default in the SDK and operator.
- Feast is not a pipeline or streaming transformation engine, so real-time features still need separate compute and orchestration, which managed platforms such as Tecton (now part of Databricks) bundle.
Recommendation
Assess Feast if you run several models on shared entities (customers, accounts, devices) and have seen training-serving skew or duplicated feature code, and you want to keep features on your own warehouse and key-value store rather than inside one vendor platform. It fits Kubernetes-based stacks best, especially OpenShift AI or Kubeflow, where a supported distribution is available. For a single batch model, or for teams already standardized on Databricks feature serving, the extra registry and serving tier is unlikely to pay off.
Scope the evaluation to one use case with an existing offline store and one online store, and set up the security baseline first: run version 0.59.0 or later, configure kubernetes or oidc auth, keep the feature and registry servers off public networks, and restrict who can register on-demand transformations. Measure point-in-time correctness, online read latency, and materialization cost, and pin versions with an upgrade test suite before any move to Trial.
Sources
- Feast docs
- Feast GitHub
- Feast concepts
- Feast releases
- Feast website
- Feast offline stores overview
- Feast authorization manager
- The Future of Feast (Feb 2024)
- Feast joins the PyTorch Ecosystem (Jan 2026)
- Red Hat: Feast in OpenShift AI
- Canonical: Charmed Feast launch
- Databricks: Tecton joining Databricks
- CVE-2026-23537 (Mend)
- CVE-2026-18941 (OpenCVE)
Related entries
Consulting
From radar to implementation
You have assessed the technologies — we help you bring them into production systems safely and measurably.

