Configure an online store with Chalk.
The Chalk online store holds the latest computed feature values for low-latency serving. This guide covers how to connect a Valkey/Redis or DynamoDB instance to your Chalk environment.
For help choosing between store options, see Choosing an Online and Offline Store.
To navigate to the setup form in the Chalk dashboard, go to Integrations > Online Stores.
Create a Valkey or Redis instance that is network-accessible from your cloud account (e.g. AWS ElastiCache, GCP Memorystore, Azure Cache for Redis, or a self-hosted cluster).
[protocol]://[host]:[port]/[database]?[query_params][#fragment]
| Part | Details |
|---|---|
| Protocol | redis:// or valkey:// for non-TLS; rediss:// or valkeys:// for TLS |
| Authentication | Add password=<token> as a query parameter if authentication is enabled |
| Cluster mode | Add clustered=true or clustered=false |
| TLS verification | Append #insecure to disable certificate verification |
redis://localhost:6379/0?clustered=false
rediss://my-cluster.cloud.com:6379/0?password=your_token&clustered=true
valkeys://my-cluster.cloud.com:6379/0?password=your_token&clustered=true#insecure
Setting up DynamoDB as your online store involves four steps:
Chalk provides vendored Terraform modules that automate steps 1–3 and output the secret name for you. See the DynamoDB Online Store Deployment guide for Terraform examples, capacity sizing, and multi-region configuration. You can also provision the table manually if you prefer.
dynamodb:///[table_name]
Ensure the IAM role associated with your Chalk cluster has read/write access to the DynamoDB table.
By default, Chalk opens a TCP connection to every replica in the cluster.
In large clusters with many replicas per shard, this can create excessive
connection fan-out per query-server instance.
Set CHALK_REDIS_REPLICA_CONNECTION_POLICY to control which replicas receive
connections.
| Policy | Description |
|---|---|
| (unset) | Connect to all replicas (default) |
UNIFORM_RANDOM | For each shard, connect to exactly one replica chosen at random at startup |
ZONAL_AFFINITY | Connect only to replicas in the same availability zone as the query server |
At client-build time the query server issues a CLUSTER SLOTS command, groups
replicas by shard, and randomly picks one per shard. Only those replicas
receive connections; reads are routed to them via the
RandomReplicaStrategy. No additional configuration is needed.
Requires two things:
CHALK_AVAILABILITY_ZONE — set on each query-server pod to the
availability zone it runs in (e.g. us-east-1a). In Kubernetes this is
typically injected via the Downward API
from the topology.kubernetes.io/zone node label.
cluster-announce-az — configured on each Valkey / Redis node so that
CLUSTER SHARDS exposes an availability-zone field per node.
At startup the query server calls CLUSTER SHARDS, collects every replica
whose availability-zone matches CHALK_AVAILABILITY_ZONE, and applies a
replica_filter so only those replicas receive connections. If no replicas
match, reads fall back to the shard primaries.
Minimum server versions: CLUSTER SHARDS is available in Redis 7.0+ and
Valkey 7.2+. The cluster-announce-az configuration is available in Valkey
8.0+. For Redis, availability-zone metadata requires an equivalent
configuration or proxy-layer support.
max_staleness to control what gets written to the online store