Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.kaireonai.com/llms.txt

Use this file to discover all available pages before exploring further.

​
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 supports four backend implementations that you can switch between via a single API call, with no code changes or redeployment required.

​
Interaction Store Backend Toggle

The active backend is stored as a tenant-level setting and can be read or changed via the API: 
# Check current backend
curl GET /api/v1/settings/interaction-store

# Switch backend
curl -X PUT /api/v1/settings/interaction-store \
  -d '{ "backend": "dynamodb" }'

​
Available Backends

BackendValueBest For
PostgreSQLpostgresqlDevelopment, small deployments (<500K customers)
AWS KeyspaceskeyspacesManaged Cassandra-compatible, moderate scale
ScyllaDBscyllaHigh throughput, low latency, self-managed
DynamoDBdynamodbServerless, auto-scaling, multi-region
postgresql is the default and requires no additional infrastructure beyond your existing database.
All four implementations exist and are fully functional. Switching the setting changes which adapter handles reads and writes immediately.

​
When to Switch

Consider moving off PostgreSQL when any of the following apply:
SignalThreshold
Customer base>500K active customers
Write throughput>1,000 writes/sec sustained
Multi-region requirementNeed cross-region replication
Query latencyInteraction queries degrading OLTP performance
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. Follow this pattern for a zero-downtime migration:

​
Step 1 — Dual-Write

Enable dual-write mode so new interactions are written to both the old and new backends simultaneously: 
curl -X PUT /api/v1/settings/interaction-store \
  -d '{ "backend": "dynamodb", "dualWrite": true, "readFrom": "postgresql" }'
During dual-write, reads continue from PostgreSQL while writes go to both stores.

​
Step 2 — Backfill from Exported Files

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

​
Step 3 — Switch Reads

Once the backfill is complete and you have verified data consistency, switch reads to the new backend: 
curl -X PUT /api/v1/settings/interaction-store \
  -d '{ "backend": "dynamodb", "dualWrite": false }'
At this point, all reads and writes 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 switching reads. Use the decision trace debug mode to verify that interaction lookups return consistent results during the dual-write phase.

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.