Skip to main content

Overview

The ThreadStore class provides a unified interface for persisting conversation threads with support for multiple storage backends: in-memory (for development), SQLite (for local storage), and PostgreSQL (for production).

Creating a ThreadStore

The factory method validates the connection immediately, catching configuration errors early.

Direct Constructor

Storage Backends

In-Memory (Default)

SQLite

PostgreSQL

Quick Docker Setup

For local development with PostgreSQL:
To manage the database:

Connection Pool Configuration

Configure connection pooling via environment variables:
int
default:"5"
Maximum number of connections to maintain in the pool
int
default:"10"
Maximum overflow connections above pool_size
int
default:"30"
Seconds to wait for a connection from the pool
int
default:"300"
Seconds after which to recycle connections

Basic operations

Saving Threads

Retrieving Threads

Listing Threads

Searching Threads

Deleting Threads

Thread Aliases

ThreadStore supports aliases - alternative IDs for threads:

Usage Statistics

Example: Multi-User Chat Application

Error handling

Best practices

  1. Use the factory method (ThreadStore.create()) for immediate validation
  2. Configure connection pools for production PostgreSQL deployments
  3. Use aliases for integrating with external systems (Slack, Discord, etc.)
  4. Don’t store sensitive data in thread attributes - they’re not encrypted
  5. System messages aren’t persisted - add them dynamically when needed
  6. Use search sparingly - it can be expensive on large datasets

Migration Between Backends