Feast Online Store Implementations: Redis vs DynamoDB vs SQLite Comparison

Feast ships with three primary online store backends—Redis, DynamoDB, and SQLite—all implementing the OnlineStore abstract class in feast/infra/online_stores/online_store.py, enabling sub-millisecond to low-single-digit millisecond feature retrieval depending on your infrastructure requirements.

Feast (feast-dev/feast) is an open-source feature store that abstracts feature serving through pluggable online store implementations. These backends handle the critical path of low-latency feature retrieval for real-time model inference. Selecting between Redis, DynamoDB, or SQLite depends on your deployment environment, latency requirements, and operational constraints.

Core Online Store Architecture

All implementations inherit from the OnlineStore abstract base class defined in feast/infra/online_stores/online_store.py. This interface standardizes methods including online_write_batch(), online_read(), update(), and teardown(), ensuring that switching backends requires only configuration changes without application code modifications.

Each store persists entity rows—feature values keyed by entity identifiers—using distinct storage formats optimized for their underlying technology.

Redis Online Store

The RedisOnlineStore class in feast/infra/online_stores/redis.py provides high-performance, in-memory feature caching suitable for production serving at scale.

Storage Format

Redis stores each entity row as a Redis hash. The hash key uses a protobuf-encoded RedisKeyV2 structure (defined in the online store format specification). Feature names are hashed using Murmur3 and stored as hash fields, while timestamps are preserved under a special "_ts:<table>" field. This design enables O(1) reads and writes, with Feast updating entire rows via atomic HMSET pipeline operations.

Deployment Modes

The implementation supports three Redis configurations via RedisOnlineStoreConfig:

• Single node: Direct connection to standalone Redis
• Redis Cluster: Horizontal partitioning for scalability
• Redis Sentinel: High availability with automatic failover

Performance Characteristics

• Latency: Sub-millisecond (network-local)
• Scalability: Horizontal scaling via Redis Cluster or Sentinel
• Durability: Optional disk persistence (RDB/AOF), though primarily an in-memory cache
• Vector search: Supported via application-side lookups (vectors stored as BLOBs); no native ANN indexing

DynamoDB Online Store

The DynamoDBOnlineStore in feast/infra/online_stores/dynamodb.py offers a fully managed, cloud-native solution for AWS environments.

Storage Format

DynamoDB stores each entity row as an item with a primary key entity_id (containing the hash of the serialized EntityKey). Feature values reside in a map attribute named values, while event_ts stores the timestamp separately. The implementation leverages DynamoDB's batch get (BatchGetItem) for reads and batch writer for writes, automatically handling unprocessed items and retries.

Configuration Options

Key parameters in DynamoDBOnlineStoreConfig include:

• region: AWS region for table deployment
• table_name_template: Pattern for table naming (default: "{project}.{table_name}")
• batch_size: Items per BatchGetItem call (default: 100)
• consistent_reads: Boolean for strong consistency versus eventual consistency

Performance Characteristics

• Latency: Low-single-digit milliseconds (AWS network), higher with eventual consistency
• Scalability: Unlimited throughput via DynamoDB auto-scaling, provisioned or on-demand capacity
• Durability: Strong durability and high availability managed by AWS
• Operational overhead: Requires IAM permissions and table provisioning (or Terraform), but no cluster management

SQLite Online Store

The SqliteOnlineStore in feast/infra/online_stores/sqlite.py provides an embedded, file-based solution designed for local development and testing.

Storage Format

SQLite persists rows in local tables named <project>_<feature_view>. The schema includes entity_key BLOB, feature_name TEXT, value BLOB, optional vector_value BLOB, and timestamp fields. When vector_enabled=True, Feast loads the sqlite_vec extension to execute approximate nearest neighbor (ANN) queries directly within the database. Full-text search is available via SQLite's fts5 virtual table when text_search_enabled=True.

Use Cases

This backend is optimized for:

• Local development and debugging
• Unit testing without external dependencies
• Very small workloads with zero operational overhead

Performance Characteristics

• Latency: Sub-millisecond (local process)
• Scalability: Limited to host machine resources; not recommended for production serving
• Durability: File-based persistence without replication
• Vector/Search capabilities: Native support via sqlite_vec and fts5 extensions

Feature Comparison Matrix

Feature	Redis	DynamoDB	SQLite
Primary Class	RedisOnlineStore – feast/infra/online_stores/redis.py	DynamoDBOnlineStore – feast/infra/online_stores/dynamodb.py	SqliteOnlineStore – feast/infra/online_stores/sqlite.py
Latency	Sub-millisecond	Low-single-digit ms	Sub-millisecond
Scalability	Horizontal (Cluster/Sentinel)	Unlimited (AWS managed)	Single machine only
Vector Search	Application-side only	Application-side only	Native (via sqlite_vec)
Full-Text Search	❌	❌	✅ (via fts5)
Operational Complexity	Requires Redis management	Requires AWS IAM and provisioning	Zero-ops (file-based)
Typical Use Case	Production low-latency serving	Cloud-native fleet serving	Local development

Configuration Examples

Define your backend in feature_store.yaml by specifying the type field, which maps to the respective implementation class:

Redis Configuration

online_store:
  type: redis
  redis_type: redis              # Options: redis | redis_cluster | redis_sentinel

  connection_string: localhost:6379
  key_ttl_seconds: 86400         # Optional TTL for entity rows

DynamoDB Configuration

online_store:
  type: dynamodb
  region: us-east-1
  table_name_template: "{project}.{table_name}"
  batch_size: 100
  consistent_reads: false

SQLite Configuration

online_store:
  type: sqlite
  path: data/online.db           # Relative to repo root

  text_search_enabled: false
  vector_enabled: false

Python Usage Examples

All three implementations expose identical Python APIs through the FeatureStore class in feast/feature_store.py.

Initializing the Store

from feast import FeatureStore

# Loads configuration from feature_store.yaml

store = FeatureStore(repo_path="my_feature_repo")

Writing Feature Values

from datetime import datetime
from feast import Entity, FeatureView
from feast.types import Float32

# Define a feature view

driver_stats = FeatureView(
    name="driver_hourly_stats",
    entities=[Entity(name="driver_id", join_key="driver_id")],
    schema=[Float32(name="conv_rate")],
)

# Prepare data: list of (EntityKey, {feature: Value}, event_ts, created_ts)

data = [
    (
        driver_stats.entity_key(driver_id="1001"),
        {"conv_rate": Float32(0.73).to_proto()},
        datetime.utcnow(),
        None,
    ),
]

# Writes execute differently per backend:

# Redis: HMSET pipeline | DynamoDB: batch_writer | SQLite: INSERT ... ON CONFLICT

store.write_to_online_store(driver_stats, data)

Reading Online Features

# Build entity keys for retrieval

entity_keys = [
    driver_stats.entity_key(driver_id="1001"),
    driver_stats.entity_key(driver_id="1002"),
]

# Retrieval methods:

# Redis: HMGET per entity (batched via pipeline)

# DynamoDB: BatchGetItem with configured batch_size

# SQLite: SELECT ... WHERE entity_key IN (...)

features = store.get_online_features(
    feature_refs=["driver_hourly_stats:conv_rate"],
    entity_keys=entity_keys
)

Infrastructure Management

# Creates or updates underlying tables/keys

store.update()

# Removes all persisted data:

# Redis: Deletes keys | DynamoDB: Drops tables | SQLite: Deletes file

store.teardown()

Summary

• Redis (feast/infra/online_stores/redis.py) delivers sub-millisecond latency for production serving but requires Redis cluster management and lacks native vector indexing.
• DynamoDB (feast/infra/online_stores/dynamodb.py) provides unlimited cloud scalability with minimal operational overhead, ideal for AWS-centric architectures accepting slightly higher latency.
• SQLite (feast/infra/online_stores/sqlite.py) offers zero-dependency local development with unique capabilities for vector search (sqlite_vec) and full-text search (fts5), but is unsuitable for production workloads.
• All implementations conform to the OnlineStore interface, enabling backend swaps through configuration changes alone.

Frequently Asked Questions

How do I choose between Redis and DynamoDB for production?

Redis excels when you need sub-millisecond latency and can manage Redis Cluster or Sentinel infrastructure. DynamoDB is preferable for cloud-native deployments requiring automatic scaling and high availability without operational maintenance, though it introduces slightly higher network latency (low-single-digit milliseconds). Choose Redis for performance-critical paths and DynamoDB when you prioritize managed infrastructure over raw speed.

Does SQLite support vector search for semantic similarity?

Yes. When you enable vector_enabled: true in the SQLite configuration, Feast loads the sqlite_vec extension in feast/infra/online_stores/sqlite.py (lines 85-98) to perform approximate nearest neighbor (ANN) queries directly in the database. This is unique among the built-in online stores—Redis and DynamoDB store vectors as BLOBs but require application-side similarity computation.

Can I migrate from one online store to another without code changes?

Yes. Because all implementations inherit from the OnlineStore abstract class and expose identical methods (online_write_batch, online_read, update, teardown), you can switch backends by modifying only the online_store block in your feature_store.yaml. No application code changes are required, though you must migrate existing data separately as each store uses different physical storage formats.

Why does Redis use Murmur3 hashing for feature names?

The RedisOnlineStore implementation hashes feature names using Murmur3 to generate consistent, compact hash field names within Redis hashes. This occurs in feast/infra/online_stores/helpers.py and ensures that feature lookups remain O(1) while keeping the Redis hash structure compact and efficient for the HMSET and HMGET operations used during batch writes and reads.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}