Overview
TheThreadStore 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
Recommended: Factory Method
Direct Constructor
Storage Backends
In-Memory (Default)
SQLite
PostgreSQL
Quick Docker Setup
For local development with PostgreSQL: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
- Use the factory method (
ThreadStore.create()) for immediate validation - Configure connection pools for production PostgreSQL deployments
- Use aliases for integrating with external systems (Slack, Discord, etc.)
- Don’t store sensitive data in thread attributes - they’re not encrypted
- System messages aren’t persisted - add them dynamically when needed
- Use search sparingly - it can be expensive on large datasets