Proprietary Feature Stores Hold
Überblick
Proprietäre Feature Stores ohne offene Export-Pfade erzeugen Lock-in für Training und Serving. Feast und Warehouse-native Patterns reduzieren doppelte Storage und beschleunigen Agent-Feature-Zugriff (Feast).
Hold neue Verträge ohne Export zu offenen Tabellen oder APIs. Exit-Klauseln und Batch-Export sollten vor der Produktionsabhängigkeit verhandelt sein.
Adoptionssignale
- Google hat Vertex AI Feature Store (Legacy) am 17. Februar 2026 abgekündigt, seit dem 17. Mai 2026 keine neuen Funktionen mehr ergänzt und schaltet die APIs am 17. Februar 2027 ab (Vertex AI Deprecations).
- Googles Nachfolger, inzwischen als Agent Platform Feature Store dokumentiert, hält Feature-Daten in BigQuery-Tabellen oder -Views, die den Offline Store bilden; der Anbieter selbst ist damit auf ein Warehouse-natives Design umgestiegen (Agent Platform Feature Store).
- Tecton ist im August 2025 zu Databricks gewechselt (Databricks Blog), und Redis hat im Oktober 2025 Featureform übernommen, um es in das eigene Angebot zu integrieren (SD Times).
- Lakehouse-Anbieter liefern Feature Serving inzwischen auf eigenem Storage aus: Databricks betreibt seinen Online Feature Store auf Lakebase, synchronisiert aus Offline-Feature-Tabellen (Databricks Online Feature Store).
- Die offene Alternative wird gepflegt und ist breit anschlussfähig: Feast steht unter Apache 2.0, hat am 21. August 2026 v0.66.0 veröffentlicht und unterstützt Offline Stores wie Snowflake, BigQuery, Redshift, Spark und PostgreSQL sowie Online Stores wie Redis, DynamoDB und PostgreSQL (Feast GitHub).
Risiken
- Erzwungene Migrationen. Die Abschaltung von Vertex AI Feature Store (Legacy) zwingt Kunden auf einen Nachfolger, dessen Offline Store aus BigQuery-Tabellen oder -Views besteht (Vertex AI Deprecations, Agent Platform Feature Store); vergleichbarer Aufwand droht bei jedem proprietären Store, der umbenannt, zusammengelegt oder eingestellt wird, und zwar nach dem Zeitplan des Anbieters.
- Roadmap-Risiko durch Übernahmen. Nach dem Wechsel von Tecton zu Databricks enthielt die Ankündigung keine datierten Zusagen für Bestandskunden (Databricks Blog); Verträge ohne Exit-Klauseln machen Kunden von den Produktplänen des Käufers abhängig.
- Lock-in der Logik, nicht nur der Daten. Transformationen, Aggregationsfenster und Backfill-Semantik, die in einem Anbieter-SDK definiert sind, haben kein portables Format; Teams, die nur den Datenexport verhandelt haben, stehen trotzdem vor einem Rewrite.
- Doppelte Speicherung und Governance. Ein separater Offline Store neben Lakehouse oder Warehouse dupliziert Daten, Zugriffsrichtlinien und Lineage, was DSGVO-Löschungen und Audits für regulierte Teams erschwert.
Vorteile & Nachteile
Vorteile
- Sie versprechen Echtzeit-Serving, ohne es selbst bauen zu müssen: Databricks beschreibt Tectons Managed Platform mit Latenzen unter 10 ms und 99,99 % Uptime, was mit eigenen Streaming-Jobs und Online-Caches schwer zu erreichen ist.
- Ein einziges SDK übernimmt point-in-time-korrekte Trainingsdaten, Backfills und Online Serving und beseitigt damit eine Klasse von Training/Serving-Skew-Fehlern, die kleine ML-Teams allein kaum verhindern.
- Cloud-ML-Suiten bündeln einen Feature Store mit Notebooks, Training und Model Serving; Teams, die bereits auf dieser Cloud arbeiten, bekommen einen Vertrag, ein IAM-Modell und einen Support-Kanal.
Nachteile
- Anbieter ändern oder beenden diese Produkte nach eigenem Zeitplan: Google hat Vertex AI Feature Store (Legacy) im Februar 2026 abgekündigt und schaltet die APIs im Februar 2027 ab; Kunden müssen auf einen Nachfolger mit anderem, BigQuery-basiertem Design umziehen.
- Eigenständige Feature-Plattformen werden von größeren Anbietern übernommen: Tecton ist 2025 zu Databricks gewechselt, die Website leitet inzwischen dorthin weiter, und Redis hat Featureform gekauft. Kunden bleiben mit Roadmaps zurück, die sie nicht steuern.
- Der Export von Feature-Werten ist kein Ausstieg: Feature-Logik, Backfill-Jobs und Online-Serving-Verträge liegen im SDK des Anbieters und müssen beim Wechsel zu Feast oder einem Warehouse-nativen Ansatz neu geschrieben werden.
Empfehlung
Hold für neue Bindungen an Feature Stores, die Feature-Definitionen und Offline-Daten in einem proprietären Format halten. Neue ML- und Agent-Feature-Arbeit sollte bei Feature-Tabellen im bestehenden Warehouse oder Lakehouse beginnen (Delta-, Iceberg-, BigQuery- oder Snowflake-Tabellen); Feast oder das native Feature Serving der Plattform kommt nur für den Online-Pfad hinzu. Transformationen gehören in SQL, dbt oder schlichtes Python, damit sie einen Wechsel der Serving-Schicht überstehen.
Ist eine Managed Feature Platform für Echtzeit-Features im Millisekundenbereich dennoch nötig, sollte sie als austauschbare Serving-Komponente behandelt werden: die Offline-Quelle der Wahrheit in eigenen offenen Tabellen halten, Exit-Klauseln und Datenexport in den Vertrag schreiben und die Logik jedes Features außerhalb des Anbieter-SDK dokumentieren. Bestehende Nutzer von Vertex AI Feature Store (Legacy) oder Tecton sollten Migration oder Neuverhandlung jetzt einplanen und nicht erst zur Frist des Anbieters.
Quellen
Beratung
Vom Radar zur Umsetzung
Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.
