Databricks Online Feature Stores are the current low-latency serving layer for feature data used by real-time ML and AI applications. Databricks now powers new Online Feature Stores with Lakebase Autoscaling, synchronizing governed offline feature tables from Unity Catalog into a PostgreSQL-compatible online database for fast lookup. Models logged with Databricks Feature Engineering can automatically retrieve these features during Model Serving, while Feature Serving endpoints can expose feature values directly to non-Databricks applications.
Within Generative AI on Databricks, online features support use cases such as personalization, fraud/risk context, recommendations, agent context, and low-latency structured retrieval that changes more frequently than a document RAG corpus.
The feature-serving path should be chosen only when the application needs current structured values at inference time; static model inputs or batch workloads can often stay in the offline Unity Catalog feature table.
Lakebase is the current managed online-store backend
Current Databricks documentation says new Online Feature Stores are created as Lakebase Autoscaling projects.
The online store maintains low-latency access while Databricks tracks lineage back to the offline Unity Catalog feature table.
Platform teams should update older architecture diagrams that show only DynamoDB or legacy online-store integrations when new projects are expected to use Databricks-managed online storage.
Offline features remain Delta tables in Unity Catalog
The canonical feature definition and historical values live in Unity Catalog-governed Delta tables or Feature Views.
This keeps training, batch inference, lineage, ownership, and online publication connected to one governed source.
A low-latency online store should be treated as a serving replica, not a second independent feature-authoring system.
Model Serving can perform automatic feature lookup
When a model is trained/logged through Databricks Feature Engineering, the model can retain lineage to the features it needs.
At inference time, Model Serving can use entity IDs from the request to retrieve current feature values automatically from the online store.
This reduces application glue and training-serving skew because the deployed model knows which feature definitions it was trained with.
Feature Serving endpoints expose features without a model
Some applications need structured feature values directly—for example a GenAI agent that needs customer tier, product eligibility, account risk, or current inventory before calling an LLM.
Feature Serving endpoints return features through a low-latency service and can combine pre-materialized and on-demand computations.
Feature Stores for GenAI provides the broader architecture for using governed features as agent context.
Feature Views are the newer declarative authoring model
Databricks now supports Feature Views in Public Preview for declaratively defining features and letting the platform manage feature computation pipelines.
Feature Views can contain table-backed, stream-backed, request-sourced, and custom UDF-computed features with dependency graphs.
Use preview capabilities deliberately and keep a migration path for feature tables that already have stable production pipelines.
Online materialization needs a freshness SLO
Publishing a feature table does not make every value instantly current unless the materialization/update path meets the business requirement.
Track source event time, offline feature update time, online materialization time, and inference lookup time.
A recommendation agent can be technically online while using customer state that is twenty minutes stale.
On-demand features handle request-time context
Some features cannot be precomputed because they depend on the current request, such as distance between user and location or a value derived from request attributes.
Feature Engineering supports on-demand computations that combine request-supplied values with stored features.
Keep on-demand functions deterministic and inexpensive because they execute on the critical inference path.
Third-party stores are still supported for specific needs
Databricks continues to support selected external online stores such as DynamoDB, but current guidance recommends Databricks Online Feature Stores for real-time feature serving.
Use a third-party store when an existing platform, cross-system requirement, or non-Databricks operational standard justifies the extra integration.
Do not introduce a second online store merely because a legacy tutorial uses one.
Unity Catalog governs lineage and discovery
Features, source tables, served models, and online stores are connected through Unity Catalog lineage.
Use owner, tags, comments, and access control so application teams know which feature is approved and which models depend on it.
Changing a shared feature definition should trigger downstream impact review before the online serving copy is updated.
Serving limitations should be tested before architecture commitment
Current Online Feature Store documentation includes constraints around catalog/database naming, read replicas, and which online table is resolved when several are published.
Model/feature-serving deployment should be tested with the exact catalog and Lakebase layout the platform intends to standardize.
A technically valid publication can still fail at serving time if the underlying database/catalog naming assumptions do not match.
Online Feature Stores succeed when low latency does not create feature drift
The mature platform keeps one governed offline definition, publishes to Lakebase intentionally, monitors freshness, uses automatic model lookups where appropriate, exposes Feature Serving for structured agent context, and versions feature definitions alongside models.
Real-time features create value when they make current business state available to AI without sacrificing the reproducibility of training data.
Online-store capacity should be sized from lookup rate, entity key cardinality, payload width, read replicas, and latency SLO. A model-serving endpoint can autoscale faster than the feature store underneath it if capacity planning ignores the lookup backend. Load-test feature lookup and model inference together rather than separately.
Feature Serving should expose narrow FeatureSpecs rather than entire feature tables. Applications rarely need every engineered column. A small contract reduces payload size, accidental data exposure, and coupling to unrelated feature changes while making ownership and versioning clearer.
Write/materialization failures need a stale-data policy. If the online store stops syncing, decide whether the endpoint should keep serving the last known value, reject requests, or use defaults after a threshold. Monitor feature age per critical feature so the application can distinguish slightly delayed data from dangerously stale state.
Lakebase identity and network controls should be governed like any production database. Even though Databricks manages the Online Feature Store workflow, underlying access, catalogs, databases, read replicas, and serving endpoints can create operational dependencies. Keep platform ownership for backup/recovery, scaling, private access, and incident response explicit.
Feature lineage should connect online values back to the transformation code and source data used to produce them. When a customer disputes a prediction, investigators need to know not only which model ran but which feature values were retrieved and which pipeline/version created them.
On-demand feature UDFs should have deterministic timeout and fallback behavior. A slow custom UDF can dominate model latency; an exception can fail an otherwise healthy scoring request. Keep functions small, unit-tested, versioned, and free of uncontrolled network calls unless the latency/availability contract permits them.
Feature-serving contracts should be backward compatible during model rollout. If a new model needs an additional feature or different type, publish and validate the new online feature first, then deploy the model. Removing old features should wait until every model/application version that depends on them has been retired.
Cost should include Lakebase compute, read replicas, Feature Serving/Model Serving, feature pipeline compute, and storage. A low-latency store that serves mostly idle development traffic may be unnecessary; use environment-specific scale and delete online stores no longer needed.
Online feature stores need disaster-recovery expectations. If Lakebase or the serving endpoint is unavailable in a region, decide whether the model endpoint can operate from another store/region, use defaults, or fail closed. The feature backend is part of the inference critical path and deserves the same recovery design as the model endpoint.
PII and sensitive feature values should be minimized. A model might need an age band or risk score rather than raw birth date or transaction history. Compute privacy-preserving features offline where possible and publish only the values the inference contract requires.
Feature Serving clients should cache carefully. Short-lived caching can reduce lookup load for slowly changing features, but it introduces staleness and invalidation. Cache only when the feature’s business freshness permits it and record source/version timestamps so the application can reject values that are too old.
Online-store schema changes should follow a compatibility rollout: add new features, materialize/sync, validate availability, deploy consumers, then remove old fields after every consumer has migrated. This is the same expand-contract pattern used for databases and should be documented for feature views/specs.
Quality monitoring should correlate prediction errors with feature freshness/coverage. When model accuracy degrades, investigators need to know whether the model changed, the feature computation changed, or online lookups returned null/stale values. Feature lineage makes this possible when traces preserve entity/feature-version context safely.
Online-store permissions should be tested through the serving identity, not through an administrator notebook. A model or Feature Serving endpoint can fail to resolve features because the deployment identity lacks access even while engineers can query the table interactively. Include permission tests in deployment CI.
Feature-store lifecycle should remove online copies after dependent applications retire. Keeping abandoned Lakebase projects or published tables indefinitely adds cost and data exposure. Decommissioning should confirm no active model/FeatureSpec lineage references the online store before deletion.
Feature-serving contracts should remain narrow, versioned, and observable throughout the model lifecycle.
Online and offline feature definitions should be reconciled continuously. Differences in freshness, transformation logic, null handling, or key semantics can produce an apparently healthy endpoint whose real-time prediction behavior no longer matches the model’s training assumptions.
