Skip to main content

​
Overview

KaireonAI’s interaction store is the highest-volume component in the platform — every recommend and respond call reads or writes interaction data. The platform ships four backend implementations. The active backend is selected process-wide by the INTERACTION_STORE environment variable, read once at startup (default pg). An admin API records the intended backend as a tenant setting for visibility and audit, but changing the live adapter requires setting INTERACTION_STORE (plus the per-backend env vars) and restarting.

​
Interaction Store Backend Setting

The intended backend is recorded as a tenant-level setting (admin-only) and can be read or updated via the API. This records your preference and writes an audit-log entry — it does not repoint live traffic or migrate data. The runtime adapter is chosen by the INTERACTION_STORE env var.
Accepted backend values for the setting: postgresql, keyspaces, scylla, dynamodb. Note the INTERACTION_STORE env var uses pg (not postgresql) for the PostgreSQL backend.

​
Available Backends

postgresql is the default and requires no additional infrastructure beyond your existing database.
All four implementations exist and are fully functional. The runtime adapter is chosen by the INTERACTION_STORE env var at process start (default pg) — changing the tenant setting alone does not repoint reads and writes. Set the env var and restart to switch the live backend.

​
When to Switch

Consider moving off PostgreSQL when any of the following apply: For most deployments under these thresholds, PostgreSQL is the simplest and most cost-effective option.

​
Migration Path

Switching backends does not automatically migrate existing data, and there is no built-in dual-write mode. Plan an operational cutover:

​
Step 1 — Provision and Point the New Backend

Provision the target store (DynamoDB table, ScyllaDB cluster, or Keyspaces keyspace), then set INTERACTION_STORE and the matching per-backend environment variables (see Infrastructure Backends) and roll the deployment.

​
Step 2 — Backfill from Exported Files

Use the exported interaction files (Hive-partitioned NDJSON) to backfill historical data into the new backend. This avoids reading from the production PostgreSQL database during migration.

​
Step 3 — Cut Over

Once the backfill is complete and you have verified data consistency, roll the fleet onto the new INTERACTION_STORE value. All reads and writes then flow through the new backend. The old PostgreSQL interaction tables can be archived or dropped after a safety period.
Test the new backend with production-like load before cutting over. Use the decision trace debug mode to verify that interaction lookups return consistent results after the backfill.

Infrastructure Backends

Full details on all pluggable backends (cache, events, search, and more).

Retention & Archival

Export interaction history before migration or cleanup.

Capacity Planning

Size your infrastructure for production workloads.