Offline Store

The Chalk offline store persists all computed feature values — enabling monitoring and dataset generation for model training. It is backed by a data warehouse such as BigQuery, Snowflake, or Iceberg. While the online store — backed by low-latency stores like Redis or DynamoDB — caches the latest value of each feature for fast serving, the offline store retains a deep historical record of feature values, timestamped and keyed by entity.

The offline store is typically implemented using BigQuery, Snowflake, Iceberg, or other data warehouses.

​

How data flows into the offline store

Feature values can be written to the offline store from several sources:

1. Online queries — freshly computed features from online queries are automatically persisted to the offline store. This means your offline store passively accumulates a historical record of every feature value served in production.
2. Offline queries - offline queries can write to the offline store if specified.
3. Scheduled resolver runs — scheduled or triggered resolver runs execute in batch across your upstream data sources and write all computed values to the offline store.
4. Backfills — you can explicitly ingest historical feature data from external sources using batch backfilling.

​

How features are stored: Fully Qualified Names

Each feature in Chalk has a Fully Qualified Name (FQN) that uniquely identifies it. An FQN is composed of:

<namespace>.<feature_name>

The namespace comes from the @features class name (stripped of a trailing "Features" suffix if present), and the feature name comes from the Python attribute name — unless overridden via feature(name=...) or @features(name=...).

For example:

@features
class User:
    id: int
    fraud_score: float

Historical feature value tables in the offline store are named after a hash of the feature’s namespace, FQN, and internal version. More information on the historical feature value table schema can be found in Chalk catalog components.

​

Internal versioning and type safety

In addition to the FQN, Chalk tracks an internal version for every feature when naming its offline store table. This internal version is managed automatically and is separate from the explicit user-defined versions you can set with feature(version=...).

The internal version increments whenever you change the type of a feature. For example, changing fraud_score from float to int will cause Chalk to write new values into a new table, rather than mixing them with the existing one. This guarantees that the offline store never serves values of incompatible types for the same feature.

In practice:

• Type changes are safe — old data is preserved under the previous internal version and is no longer served, while new values accumulate in the new table.
• No manual migration is needed — Chalk handles the versioning automatically on deployment.
• History resets on type change — if you need to preserve historical values after a type change, backfill the new table explicitly.

​

Querying the offline store

There are a few ways to query the offline store:

Offline queries — use ChalkClient.offline_query() from the Python client to retrieve historical feature values, build training datasets, and run batch inference. See Offline Queries for the full API reference, including point-in-time lookups, spine SQL input, timebounds, and large query execution.

SQL Explorer — run SQL directly against historical feature value tables from the Chalk dashboard. Navigate to the SQL Explorer tab to query the offline store without writing any code. See Chalk SQL for more detail.

​

Offline store options

Chalk supports several offline store backends. In general, choose the store you already use in your data platform — Chalk handles routing and FQN-based isolation regardless of backend.

For GCP deployments, BigQuery is generally recommended for its performance with analytical queries. For AWS deployments, Redshift or Snowflake are common choices depending on your existing data platform.