1.10 Online vs. Offline Feature Tables
Key Takeaways
- Offline feature tables are Delta tables optimised for high-throughput scans: they hold full history, support time travel, and power training and batch scoring.
- Online feature tables are low-latency key-value stores holding only the current value per primary key, and they exist to serve single-row lookups inside a REST request.
- An online table is a published copy of an offline table, not an independent source: the offline Delta table remains the system of record and is the only place point-in-time history exists.
- Publishing runs in TRIGGERED mode (a one-shot sync per call, matched to a batch refresh schedule) or CONTINUOUS mode (a streaming sync that keeps values seconds-fresh).
- Legacy Databricks online tables are deprecated; the current managed path is the Databricks Online Feature Store backed by Lakebase, but the offline-versus-online distinction it implements is unchanged.
1.10 Online vs. Offline Feature Tables
Offline Delta Tables vs. Low-Latency Online Feature Stores
Machine learning architectures separate offline and online storage to meet divergent throughput and latency requirements:
| Offline feature store | Online feature store | |
|---|---|---|
| Engine | Delta Lake on cloud object storage | Low-latency key-value store |
| Query shape | High-throughput scans over full history | Sub-10 ms point lookups by primary key |
| Guarantees | ACID transactions and Delta time travel | Latest feature state per key only |
| Consumers | Training runs and batch scoring | Real-time model serving over REST |
The two are joined by an automated publish sync that pushes current values from the offline Delta table into the online store.
Publishing Features to an Online Store
An offline feature table becomes available for real-time serving only after it is
published. On current Databricks, the managed path is a Databricks online store;
FeatureEngineeringClient.publish_table takes the online store object plus the
source and destination table names:
from databricks.feature_engineering.online_store_spec import DatabricksOnlineStore
fe.publish_table(
online_store=DatabricksOnlineStore(name="prod_online_store"),
source_table_name="prod_catalog.ml_features.customer_demographics",
online_table_name="prod_catalog.ml_features.customer_demographics_online",
publish_mode="TRIGGERED", # or "CONTINUOUS" for streaming sync
)
publish_mode="TRIGGERED"runs a one-shot sync each time it is called — the right choice for features recomputed on a daily or hourly schedule.publish_mode="CONTINUOUS"keeps a streaming sync running so online values track the offline Delta table within seconds.- Third-party key-value stores (Amazon DynamoDB, Azure Cosmos DB, Azure SQL/MySQL)
are reached through the corresponding
OnlineStoreSpecsubclass rather than a genericOnlineStoreSpec(store_type=...)constructor. If a question offersOnlineStoreSpec(store_type="CosmosDb"), that is not a real API call.
The Differences That Get Tested
| Dimension | Offline feature table | Online feature table |
|---|---|---|
| Storage engine | Delta Lake on cloud object storage | Low-latency key-value store (Databricks online store, DynamoDB, Cosmos DB, …) |
| Access pattern | Scan and join across millions of rows | Point lookup by primary key |
| Typical latency | Seconds to minutes for a distributed job | Single-digit to low double-digit milliseconds per key |
| History retained | Full history, with Delta time travel | Latest value per key only |
| Point-in-time joins | Supported via timeseries_column | Not applicable — no history to join against |
| Who reads it | Training runs, fe.score_batch, analytics | Model Serving endpoints, low-latency applications |
| Cost profile | Cheap per byte, priced like object storage | Provisioned throughput and storage, priced per key-value capacity |
| Source of truth | Yes | No — it is a published projection |
Why Both Exist
A training job reads tens of millions of rows once. Object storage plus a distributed scan is the cheapest possible way to do that, and Delta's history is what makes point-in-time correctness possible in the first place.
A serving endpoint does the opposite: it reads one key, and it must answer inside a user-facing request budget. Opening Parquet footers, pruning files, and launching a Spark job to fetch a single row would blow a 50 ms latency target by orders of magnitude. A key-value store answers that lookup in milliseconds.
Neither engine is good at the other's job, so Databricks keeps both and synchronises them.
Freshness and the Sync Contract
The publishing mode determines how stale an online value may be:
- TRIGGERED — each
publish_tablecall performs one sync. Pair it with the job that recomputes the offline features, so online freshness equals the batch cadence (typically hourly or daily). Cheapest option, and correct for slow-moving features such as customer tenure or product attributes. - CONTINUOUS — a streaming sync runs, keeping the online store within seconds of the offline table. Required for fast-moving features such as a 5-minute transaction velocity counter.
A frequent production bug is a feature whose business meaning demands minute-level freshness being published on a daily trigger: the endpoint returns yesterday's value with no error at all.
The Decision Rule
Ask what the consumer is:
- Training, backfills, batch scoring, analytics → offline only.
- A synchronous REST endpoint or an application that needs one entity's features in milliseconds → publish the table online, and keep the offline table as the source of truth.
- Both → maintain one offline table and publish it; never maintain two independent feature pipelines, because that is precisely the train/serve skew the feature store exists to eliminate.
Where the Online Copy Physically Lives Today
The objective is conceptual — describe the differences — but the managed implementation has been renamed, so it is worth knowing what the current product is.
Databricks' original online tables were a workspace-managed key-value copy of a Delta table. Databricks has deprecated them: new online tables can no longer be created, and the documented migration target is the Databricks Online Feature Store, backed by Lakebase, Databricks' managed Postgres engine, and provisioned as a Lakebase project. For serving data that is not a feature table, the parallel construct is a Lakebase synced table — a read-only Postgres table kept in sync with a Unity Catalog table.
None of that changes the distinction the exam tests. Offline is Delta on object storage, holds history, and serves scans. Online is a key-value engine, holds current state, and serves point lookups. An answer claiming that an online store keeps history, or that you should train from it, is wrong regardless of which generation of the product it names.
Controlling What Gets Published
publish_table does more than copy a whole table, and the extra arguments show up in
scenario questions:
| Argument | Effect |
|---|---|
filter_condition | A SQL predicate limiting which rows are published — for example only active customers, instead of ten years of closed accounts |
features | Publishes a subset of feature columns rather than all of them |
publish_mode | TRIGGERED for a one-shot sync, CONTINUOUS for a streaming sync |
mode | merge upserts by primary key into the online table |
checkpoint_location, trigger | Streaming plumbing used when the sync runs continuously |
Publishing a filtered subset is the standard cost control. Online storage is priced well above object storage, so the online copy should hold only the keys an endpoint can actually be asked about.
Two Failure Modes Worth Recognising
A key that was never published. An endpoint asks for customer_id = 'C-90412', the
online table has no such row, and the lookup returns null — it does not fall back to the
offline table. If filter_condition excluded that segment, the model silently scores on
missing features. The fix belongs in the publish filter, not the endpoint.
A schema change applied offline only. Adding a feature column to the offline Delta table does not retroactively add it online; the table must be republished. A model version trained on the new column fails its lookups until the sync catches up, which is why feature-schema changes and model promotion are sequenced deliberately rather than shipped together.
Why do real-time serving architectures read features from a published online store rather than querying the offline Delta feature table directly?
A team asks whether they can run a point-in-time training join directly against their online feature store to avoid maintaining the offline table. What is the correct response?
A real-time fraud endpoint uses a transaction_velocity_5min feature that must reflect activity from the last few minutes. The feature table is published to the online store with publish_mode="TRIGGERED" from a nightly job. What is the effect, and what is the fix?
An online feature table was published with filter_condition restricted to customers active in the last 90 days. A serving request arrives for a customer who churned two years ago. What happens?