Feast provides **native integration** with [MLflow](https://mlflow.org/) for automatic feature lineage tracking alongside ML experiments. When enabled, every feature retrieval is logged to the active MLflow run.

- **Which features did this model use?** -- auto-logged on every `get_historical_features()` / `get_online_features()` call

- **Which feature service should I use to serve this model?** -- resolved from model URI via `store.mlflow.resolve_features()`

- **Can I reproduce the exact training data?** -- entity DataFrame saved as an MLflow artifact

- **Which models break if I change a feature view?** -- reverse index via the Feast UI `/api/mlflow-feature-usage` endpoint

- **When was the feature store last updated?** -- `feast apply` and `feast materialize` logged to a separate ops experiment

| Capability | How |

|---|---|

| Auto-log feature metadata | Tags on every retrieval inside an active MLflow run |

| Entity DataFrame archival | `entity_df.parquet` artifact for full reproducibility |

| Model registration with lineage | `feast.feature_service` tag propagated to model versions |

| Training-to-prediction linkage | `store.mlflow.load_model()` links prediction runs back to training runs |

| Model-to-feature resolution | Map any model URI back to its Feast feature service |

| Operation audit trail | `feast apply` / `feast materialize` logged to `{project}-feast-ops` |

| `store.mlflow` API | Single entry point — zero `import mlflow`, zero client objects |

| Feast UI integration | Per-feature-view usage stats and registered model associations |

MLflow is an optional dependency:

pip install feast[mlflow]

Add the `mlflow` section to your `feature_store.yaml`:

project: my_project

registry: data/registry.db

provider: local

online_store:

type: sqlite

path: data/online_store.db

mlflow:

enabled: true

tracking_uri: http://127.0.0.1:5000 # optional, falls back to MLFLOW_TRACKING_URI env var

auto_log: true # default

auto_log_entity_df: false # default

entity_df_max_rows: 100000 # default

log_operations: false # default

ops_experiment_suffix: "-feast-ops" # default

The tracking URI is resolved in this order:

When `auto_log: true` and an active MLflow run exists, each `get_historical_features()` or `get_online_features()` call records:

When `auto_log_entity_df: true` and the entity DataFrame has fewer than `entity_df_max_rows` rows:

When a model is logged via `store.mlflow.log_model()`:

Regardless of `auto_log_entity_df`, the following metadata is logged when present:

When `log_operations: true`, `feast apply` and `feast materialize` create self-contained runs in the `{project}{ops_experiment_suffix}` experiment (default: `my_project-feast-ops`):

With the configuration above, feature metadata is logged automatically whenever there is an active MLflow run. No explicit `import mlflow` is needed — just use `store.mlflow`:

`store.mlflow` is the primary way to interact with the Feast–MLflow integration. It provides Feast-enhanced versions of common MLflow operations, and delegates everything else to the raw `mlflow` module:

For users who prefer a module-level import, `feast.mlflow` is a **drop-in replacement for `import mlflow`** that delegates to the same `store.mlflow` client under the hood:

`feast.mlflow` resolves its `FeatureStore` in this order:

`feast.mlflow` raises clear errors on first use if something is misconfigured:

These functions add automatic Feast tagging and lineage on top of their MLflow counterparts:

These are unique to the Feast integration and have no `mlflow` equivalent:

The `feast.mlflow` module delegates any attribute not listed above to the raw `mlflow` module. This means you can use `feast.mlflow` as a drop-in replacement for `import mlflow`:

`store.mlflow` does **not** have this passthrough — it only exposes the Feast-enhanced and Feast-only methods listed above. To access raw `mlflow` functions from `store.mlflow`, use the escape hatches:

Resolution order:

This requires `auto_log_entity_df: true` to have been enabled when the original run was recorded.

The Feast UI server exposes three API endpoints that aggregate data from MLflow:

The feature view detail page in the Feast UI displays:

- An **MLflow Usage** panel showing training run count, relative last-used time, and a table of registered models that depend on the feature view

Start the Feast UI with: