Feast vs Hopsworks

Verdict

Both are open source and can be self-hosted with no licence fee, but they solve a different amount of the problem. Feast is governed by the Linux Foundation and deliberately stays narrow: it manages feature definitions and materializes them into an online store such as Redis or DynamoDB, but it does not compute features itself — you bring an existing feature-engineering pipeline. Hopsworks includes its own compute for feature pipelines via Spark, Python or Flink, and bundles a model registry and model serving alongside the feature store, aimed at teams that want those pieces together rather than integrated separately.

Choose Feast if

• You already have a feature-engineering pipeline and only need a registry and serving layer on top of it.
• You want a vendor-neutral project with no single company controlling its direction.
• You want the lightest possible addition to an existing self-hosted stack.

Choose Hopsworks if

• You want feature computation, storage, model registry and model serving in one platform rather than several integrated tools.
• You need a genuine self-hosted or air-gapped deployment for on-premises or regulated environments, with commercial support available.
• Point-in-time joins between an offline training store and an online serving store should be handled by the platform, not assembled by hand.

What they share

Both target the same core problem — training/serving skew between features computed for model training and features computed for live inference — and both offer batch and streaming ingestion. See feature store and machine learning for the underlying concept. Neither is billed inside a cloud platform's usage the way Databricks Feature Store or SageMaker Feature Store are, so if you are already committed to one of those clouds, price the migration honestly before switching.