Feast Assess

Überblick

Feast ist die führende offene Feature-Store-Abstraktion für Offline- und Online-Serving über Warehouses und Redis-ähnliche Stores (Feast).

Assess, wenn ML- und Agent-Features zwischen Training und Serving konsistent sein müssen. Tecton, 2025 von Databricks übernommen, zielt auf gemanagte Echtzeit-SLAs im Enterprise-Umfeld; Feast punktet bei OSS-Kontrolle (Databricks zu Tecton).

Adoptionssignale

• Aktiver Release-Rhythmus: v0.62 bis v0.66 erschienen zwischen April und August 2026 und brachten unter anderem Offline Stores für Oracle, Ray und MongoDB, Online Stores für Aerospike und ScyllaDB, eine Apache-Flink-Compute-Engine und Data Quality Monitoring (Feast Releases).
• Auf der Projektseite genannte Anwender sind unter anderem Robinhood, NVIDIA, Discord, Cloudflare, Walmart, Shopify, Capital One, Expedia, HelloFresh und Adyen; die Seite nennt 293 Contributors und über 12 Mio. Downloads (Stand September 2026), das Repository hat rund 7.300 GitHub-Sterne (Feast, Feast GitHub).
• Red Hat hat Feast als Feature Store in OpenShift AI 2.20 integriert (Technology Preview, Mai 2025); ein Red-Hat-Engineer ist Feast-Maintainer (Red Hat Blog).
• Canonical hat im Juli 2025 Charmed Feast als produktionsreife Distribution vorgestellt, die neben Charmed Kubeflow läuft und bis zu zehn Jahre Security-Maintenance erhält (Canonical).
• Die Governance ist breiter geworden: 2024 kamen Maintainer von Affirm, Red Hat und J.P. Morgan hinzu, mit dem erklärten Ziel eines 1.0-Release (The Future of Feast); im Januar 2026 ist Feast dem PyTorch Ecosystem beigetreten (Feast Blog).

Risiken

• Unsichere Defaults und Server-CVEs. CVE-2026-23537 (CVSS 9.1) erlaubte in allen Versionen vor 0.59.0 nicht authentifiziertes Schreiben beliebiger JSON-Dateien über den Feature Server (Mend); CVE-2026-18941 betrifft den no_auth-Default in SDK und Operator, durch den die Endpunkte von Feature-, Registry- und Offline-Server ohne Authentifizierung erreichbar waren; das ermöglichte Remote Code Execution über bösartige UDFs und mandantenübergreifende Lesezugriffe (CVSS 7.7) (OpenCVE). Die aktuelle Dokumentation beschränkt no_auth auf lokale Entwicklung (Feast Auth-Doku).
• Churn vor 1.0. Das 2024 als Ziel angekündigte 1.0-Release ist nicht erschienen; Minor Releases kommen etwa monatlich und ändern regelmäßig Verhalten von Registry und Feature Views (Feast Releases).
• Pipelines bleiben Eigenleistung. Feast ist ausdrücklich kein ETL-System, kein Orchestrator und keine Datenbank (Feast Doku); Streaming-Features, Backfills und Materialisierungs-Schedules müssen mit anderen Werkzeugen gebaut und betrieben werden.
• Ungleich reife Backends. Nur die Offline Stores für Dask, BigQuery, Snowflake und Redshift gehören zum Kern; PostgreSQL, Spark, Trino und Ray sind Community-Beiträge, die laut Dokumentation weder Stabilität noch vollen Funktionsumfang garantieren (Offline Stores). Die geplante Store-Kombination sollte gezielt getestet werden.
• Konsolidierung bei Alternativen. Mit Tecton innerhalb von Databricks erhalten Databricks-Kunden Feature Serving als Plattformbestandteil, was den Build-vs-Buy-Vergleich für Feast verschiebt (Databricks zu Tecton).

Empfehlung

Feast ist ein Assess-Kandidat, wenn mehrere Modelle auf gemeinsamen Entitäten (Kunden, Konten, Geräte) arbeiten, bereits Training-Serving-Skew oder duplizierter Feature-Code aufgetreten ist und Features im eigenen Warehouse und Key-Value-Store bleiben sollen statt in einer einzelnen Vendor-Plattform. Am besten passt Feast zu Kubernetes-basierten Stacks, insbesondere OpenShift AI oder Kubeflow, für die eine unterstützte Distribution existiert. Für ein einzelnes Batch-Modell oder für Teams, die bereits auf Databricks Feature Serving standardisiert sind, lohnt sich die zusätzliche Registry- und Serving-Schicht kaum.

Die Evaluierung sollte auf einen Use Case mit bestehendem Offline Store und einem Online Store begrenzt werden, und die Security-Baseline gehört an den Anfang: Version 0.59.0 oder neuer, Auth über kubernetes oder oidc, Feature- und Registry-Server nicht aus öffentlichen Netzen erreichbar und eingeschränkte Rechte für das Registrieren von On-Demand-Transformationen. Zu messen sind Point-in-Time-Korrektheit, Online-Leselatenz und Materialisierungskosten; vor einem Wechsel nach Trial sollten Versionen gepinnt und durch eine Upgrade-Testsuite abgesichert sein.

Quellen

• 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)