# Feast Online Store Implementations: Redis vs DynamoDB vs SQLite Comparison

> Compare Feast online store implementations: Redis, DynamoDB, and SQLite. Discover sub-millisecond feature retrieval options for your infrastructure needs.

- Repository: [Feast/feast](https://github.com/feast-dev/feast)
- Tags: comparison
- Published: 2026-03-01

---

**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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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](https://github.com/feast-dev/feast/blob/master/docs/specs/online_store_format.md#redis-online-store-format)). 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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/feast/infra/online_stores/redis.py) | `DynamoDBOnlineStore` – [`feast/infra/online_stores/dynamodb.py`](https://github.com/feast-dev/feast/blob/main/feast/infra/online_stores/dynamodb.py) | `SqliteOnlineStore` – [`feast/infra/online_stores/sqlite.py`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/feature_store.yaml) by specifying the `type` field, which maps to the respective implementation class:

### Redis Configuration

```yaml
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

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

```

### SQLite Configuration

```yaml
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`](https://github.com/feast-dev/feast/blob/main/feast/feature_store.py).

### Initializing the Store

```python
from feast import FeatureStore

# Loads configuration from feature_store.yaml

store = FeatureStore(repo_path="my_feature_repo")

```

### Writing Feature Values

```python
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

```python

# 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

```python

# 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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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`](https://github.com/feast-dev/feast/blob/main/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.