Install Feast 0.65.0 Open Source Feature Store Guide

The #1 mistake when people reach for an open source feature store is installing Feast into an already-crowded ML environment. TensorFlow, older protobuf pins, and half-broken global site-packages turn a 30-second pip into an afternoon of dependency archaeology. Start clean instead.

Feast is an open source feature store used widely in ML stacks: Python SDK + CLI, feature definitions in code, point-in-time training sets from an offline store, low-latency reads from an online store. It does not replace your warehouse or compute engine – it sits on top of what you already run. Stable pin for this guide: 0.65.0 (released July 20, 2026 per the project’s GitHub releases).

System requirements before you touch pip

Match the package metadata, not the lagging sentence in older quickstarts. PyPI lists Python >= 3.10.0 for 0.65.0; the quickstart still mentions 3.9 in places – trust the package.

CPU is not the bottleneck for a local install. Disk I/O and a clean interpreter are. Production on Kubernetes is a different path: kubectl plus a cluster that can run the Feast Operator – separate from the local SDK steps below.

Official download sources (use only these)

Skip random mirrors. Pull from:

• Package: https://pypi.org/project/feast/ (0.65.0)
• Docs: https://docs.feast.dev/
• Source / releases: https://github.com/feast-dev/feast
• Project site: https://feast.dev/

No separate “installer binary” for day-one work. SDK and CLI arrive together via pip. Operator YAML in the repo is for cluster deploys only.

Install Feast 0.65.0 step by step

Pin the version. Unpinned pip install feast is fine for a throwaway laptop test. Anything you might rebuild next month needs a pin.

# 1) Fresh environment (do not skip this)
python3.11 -m venv .feast-venv
source .feast-venv/bin/activate # Windows: .feast-venvScriptsactivate
python -m pip install --upgrade pip setuptools wheel

# 2) Core install - exact version
pip install "feast==0.65.0"

# 3) Add only the extras you will configure in feature_store.yaml
# Examples (pick what you need):
pip install "feast[redis]==0.65.0"
pip install "feast[postgres]==0.65.0"
pip install "feast[aws]==0.65.0"
pip install "feast[gcp]==0.65.0"
pip install "feast[snowflake]==0.65.0"
# Vector / sqlite-vec path when you need it:
pip install "feast[sqlite-vec]==0.65.0"

Extras pull the vendor SDKs Feast expects – spelled out on the official install page. Plain feast plus a Redis online_store block in yaml is how most people hit import errors on first apply. Install the extra first; edit yaml second.

Optional Kubernetes route (cluster already running): server-side apply so CRD annotations do not blow past size limits – kubectl apply --server-side --force-conflicts -f https://raw.githubusercontent.com/feast-dev/feast/refs/heads/stable/infra/feast-operator/dist/install.yaml (stable-branch docs as of this writing; pin a tag URL when you need a frozen manifest).

First-time configuration that actually boots

Bootstrap a repo, then make the yaml match the extras you installed.

feast init my_feature_repo
cd my_feature_repo/feature_repo
# Inspect feature_store.yaml - default local provider uses file/Dask offline + SQLite online
feast apply

feast apply scans Python definitions, writes registry metadata, creates online-store tables for the provider you set. On local: SQLite files under the repo. No cloud bill. No surprise resources.

Minimum viable local feature_store.yaml shape (defaults from init are usually enough):

project: my_feature_repo
registry: data/registry.db
provider: local
online_store:
 type: sqlite
 path: data/online_store.db

Think of Feast like a well-labeled pantry, not a chef. Your pipelines still cook the features; Feast keeps the jars consistent between training night and serving lunch. People keep hunting for a “run feature engineering” button that does not exist – that model is why.

Verify the install works

feast version
# Expect Feast SDK version output reflecting 0.65.0

python -c "from feast import FeatureStore; print('import ok')"

# From feature_repo after apply - optional UI
feast ui

Good install = feast version prints 0.65.x and apply left registry/online files with no traceback. Materialize only after definitions exist (empty online tables right after apply are normal):

CURRENT_TIME=$(date -u +"%Y-%m-%dT%H:%M:%S")
feast materialize-incremental "$CURRENT_TIME"

Common install errors and fixes

• Import / FeastExtrasDependencyImportError after setting Redis, Postgres, AWS, or GCP in yaml – core-only install. Reinstall with the matching extra at the same version, e.g. pip install "feast[redis]==0.65.0".
• FeastModuleImportError mentioning sqlite_vec – optional path; community threads (including feast-dev/feast#4293) fix it with pip install sqlite_vec or feast[sqlite-vec] at the same pin.
• Protobuf / dependency resolver conflicts with TensorFlow or other stacks – leave that environment. New venv, pin feast, extras last. Global TF + Feast is a classic failure mode.
• Python 3.9 “worked in a blog post” – 0.65.0 metadata wants 3.10+. Upgrade the interpreter rather than forcing the wheel.

If feast apply complains about sources, the demo Parquet path from init is missing or the shell is not inside feature_repo. cd back and retry.

Upgrade from a previous version and uninstall

Same venv:

pip install --upgrade "feast==0.65.0"
# Re-apply extras you rely on so versions stay aligned
pip install "feast[redis]==0.65.0"

The catch in 0.65.0: total_timeout_ms was renamed to batch_total_timeout_ms (GitHub release notes, breaking changes). Old key breaks after upgrade – edit the config. No silent default swap; the name has to match.

Cleanup local infra created by apply:

cd path/to/feature_repo
feast teardown # irreversible - drops online-store tables / infra Feast created

Then strip the package and env:

pip uninstall feast -y
deactivate
rm -rf .feast-venv my_feature_repo

Kubernetes? Delete FeatureStore custom resources first, then the Operator install YAML – reverse order of apply. Teardown does not remove the Operator itself.

FAQ

Do I need Docker to install Feast?

No. Local SDK install is pip + Python 3.10+. Docker or the Operator only matter when you deliberately put Feast services on a cluster.

Why does feast apply succeed but online reads return empty features?

Apply registers definitions and creates empty online tables. Values show up only after materialize (or push). Example: batch Parquet lands at 02:00 UTC → run feast materialize-incremental with a UTC end timestamp after that → then get_online_features. Empty online responses right after a clean apply are expected, not an install bug.

Should I use provider local, aws, or gcp for a first production spike?

Local until feature definitions and the materialization schedule are boring. Jumping straight to DynamoDB or BigQuery on day one stacks IAM, network, and cost failures on top of learning the registry model. Provider switch later is yaml + matching extra + credentials – not a full rewrite. Feast is built that way. Sequence that works: extra install → non-prod project → change provider → re-apply.

Next action: create the venv, pip install "feast==0.65.0", run feast init, and stop only after feast version and a clean feast apply both succeed. Redis, cloud stores, Operator – all of that builds on a green baseline.