Persistence backend plugins extend PraisonAI with custom storage solutions for conversations, knowledge, and state management through a centralized registry system.Documentation Index
Fetch the complete documentation index at: https://docs.praison.ai/llms.txt
Use this file to discover all available pages before exploring further.
Quick Start
How It Works
The plugin system provides three global registries for different storage types:| Registry | Kind | Entry-point Group | Purpose |
|---|---|---|---|
CONVERSATION_STORES | "conversation" | praisonai.conversation_stores | Chat history and sessions |
KNOWLEDGE_STORES | "knowledge" | praisonai.knowledge_stores | Vector databases and RAG |
STATE_STORES | "state" | praisonai.state_stores | Application state and cache |
Registry API Reference
EachStoreRegistry provides a thread-safe API for backend management:
| Method | Signature | Description |
|---|---|---|
register | register(name: str, factory: Callable, *, aliases=()) -> None | Register a backend factory with optional aliases |
create | create(name: str, **kwargs) -> Any | Create a store instance by name or alias |
list_registered | () -> list[str] | Get all registered backend names (sorted) |
list_aliases | () -> dict[str, str] | Get alias → canonical name mappings |
Built-in Backends
Conversation Stores
Primary backends:postgres, async_postgres, mysql, async_mysql, sqlite, async_sqlite, json, singlestore, supabase, surrealdb, turso
Aliases available:
neon,cockroachdb,crdb,cockroach,xata→postgresasyncpg,postgres_async→async_postgresaiomysql,mysql_async→async_mysqlaiosqlite,sqlite_async→async_sqlitelibsql→turso
Knowledge Stores
Primary backends:chroma, qdrant, pinecone, weaviate, lancedb, milvus, pgvector, redis, cassandra, clickhouse, mongodb_vector, couchbase, singlestore_vector, surrealdb_vector, upstash_vector, lightrag, langchain, llamaindex, cosmosdb
Aliases available:
chromadb→chromamongodb_atlas,mongo_vector→mongodb_vectorsinglestore_v→singlestore_vectorsurrealdb_v→surrealdb_vectorupstash_v→upstash_vectorlangchain_adapter→langchainllama_index,llamaindex_adapter→llamaindexcosmos,azure_cosmos,cosmosdb_vector→cosmosdb
State Stores
Primary backends:redis, dynamodb, firestore, mongodb, async_mongodb, upstash, memory, gcs
Aliases available:
motor,mongodb_async→async_mongodb
Common Patterns
Custom Database Adapter
Custom Database Adapter
Multi-Backend Package
Multi-Backend Package
Listing Available Backends
Listing Available Backends
Best Practices
Thread Safety
Thread Safety
All registries are thread-safe with
threading.Lock protection. Registrations and creations can be called concurrently without external synchronization. Factory functions should also be thread-safe if used in multi-threaded environments.Error Handling
Error Handling
Registry creation raises
ValueError for unknown backends with a list of available options. Factory functions should handle their own connection errors and invalid parameters appropriately.Lazy Loading
Lazy Loading
Built-in backends use lazy imports to avoid loading unused dependencies. Follow this pattern in custom backends to minimize startup time and reduce import-time failures.
Naming Conventions
Naming Conventions
- Use lowercase names without special characters
- Provide meaningful aliases for user convenience
- Follow existing patterns:
async_*for async variants,*_vectorfor vector stores - Avoid conflicts with built-in backend names
Related
Framework Adapter Plugins
Plugin system for multi-agent frameworks
Persistence Overview
Storage backends and configuration

