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.


Valkey / Redis

Create an instance

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).

Connection URI format

[protocol]://[host]:[port]/[database]?[query_params][#fragment]
PartDetails
Protocolredis:// or valkey:// for non-TLS; rediss:// or valkeys:// for TLS
AuthenticationAdd password=<token> as a query parameter if authentication is enabled
Cluster modeAdd clustered=true or clustered=false
TLS verificationAppend #insecure to disable certificate verification

Examples

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

Apply the configuration

  1. Store the connection URI as a secret in your secret manager.
  2. In the Chalk dashboard (Integrations > Online Stores), enter the secret name in the form.
  3. Click Save and Apply. Chalk will restart the relevant system resources with the new online store.

DynamoDB

Create an instance

Setting up DynamoDB as your online store involves four steps:

  1. Create a DynamoDB table in your AWS account.
  2. Construct the connection URI.
  3. Store the URI as a secret.
  4. Enter the secret name in the Chalk dashboard.

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.

Connection URI format

dynamodb:///[table_name]

Ensure the IAM role associated with your Chalk cluster has read/write access to the DynamoDB table.

Apply the configuration

  1. Store the connection URI as a secret in your secret manager.
  2. In the Chalk dashboard (Integrations > Online Stores), enter the secret name in the form.
  3. Click Save and Apply. Chalk will restart the relevant system resources with the new online store.

Valkey / Redis replica connection policies

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.

PolicyDescription
(unset)Connect to all replicas (default)
UNIFORM_RANDOMFor each shard, connect to exactly one replica chosen at random at startup
ZONAL_AFFINITYConnect only to replicas in the same availability zone as the query server

UNIFORM_RANDOM

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.

ZONAL_AFFINITY

Requires two things:

  1. 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.

  2. 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.