- InMemoryTrackerStore: Stores conversations in memory (default). Suitable for development and testing.
- SQLTrackerStore: Uses SQL databases (PostgreSQL, SQLite, Oracle) for persistent storage.
- RedisTrackerStore: Leverages Redis for fast in-memory storage with optional persistence.
- MongoTrackerStore: Stores conversations in MongoDB, a document-oriented NoSQL database.
- DynamoTrackerStore: Uses AWS DynamoDB for cloud-based storage.
TrackerStore class if you need to integrate with a different storage backend.
User-Scoped Tracker Querying
New in 3.16Rasa tracker stores now support user-scoped querying of conversations (referred to as trackers) and durable conversation metadata.
user_id and conversation_started_timestamp.
These properties enable efficient retrieval of all conversations for a specific user.
Conversation Properties
Tracker stores persist the following fields in the tracker object:user_id: The unique identifier for the user associated with the conversation. This field is used for querying all conversations belonging to a specific user. Serialization of trackers omitsnulluser_idvalues to optimize storage.conversation_started_timestamp: The timestamp when the conversation was first started. This field is used for ordering conversations chronologically.current_session_id: The session ID for the tracker’s current session, derived from the metadata of the last stored event. This value isnullwhen the last event isConversationInactive, correctly reflecting that no active session exists.
The
conversation_started_timestamp is automatically backfilled on save/update for backward compatibility with existing trackers that may not have this field.InMemoryTrackerStore (default)
InMemoryTrackerStore is the default tracker store. It is used if no other
tracker store is configured. It stores the conversation history in memory.
As this store keeps all history in memory, the entire history is lost if you restart the Rasa server.
Configuration
No configuration is needed to use theInMemoryTrackerStore.
User-Scoped Querying
TheInMemoryTrackerStore implements user-scoped tracker querying by scanning all stored tracker keys and retrieving each tracker to filter by user_id.
Implementation Details
- Full Scan: The implementation scans all stored tracker keys in memory and retrieves each tracker to filter by
user_id. This approach is feasible for in-memory storage due to the typically smaller dataset size. - Ordering and Pagination: After filtering, the trackers are ordered by
conversation_started_timestampandsender_id, and paginated in memory using standard Python sorting and slicing techniques.
SQLTrackerStore
You can use anSQLTrackerStore to store your assistant’s conversation history in an SQL database.
Configuration
To set up Rasa with SQL the following steps are required:- Add required configuration to your
endpoints.yml:
endpoints.yml
- To start the Rasa server using your SQL backend,
add the
--endpointsflag, e.g.:
Configuration Parameters
domain(default:None): Domain object associated with this tracker storedialect(default:sqlite): The dialect used to communicate with your SQL backend. Consult the SQLAlchemy docs for available dialects.url(default:None): URL of your SQL serverport(default:None): Port of your SQL serverdb(default:rasa.db): The path to the database to be usedusername(default:None): The username which is used for authenticationpassword(default:None): The password which is used for authenticationevent_broker(default:None): Event broker to publish events tologin_db(default:None): Alternative database name to which initially connect, and create the database specified bydb(PostgreSQL only)query(default:None): Dictionary of options to be passed to the dialect and/or the DBAPI upon connect
Compatible Databases
The following databases are officially compatible with theSQLTrackerStore:
- PostgreSQL
- Oracle > 11.0
- SQLite
Configuring Oracle
To use the SQLTrackerStore with Oracle, there are a few additional steps. First, create a databasetracker in your Oracle database and create a user with access to it.
Create a sequence in the database with the following command, where username is the user you created
(read more about creating sequences in the Oracle Documentation):
oracle.rpm and store it in the directory from where you’ll be building the docker image.
Copy the following into a file called Dockerfile:
endpoints.yml as described above,
and start the container. The dialect parameter with this setup will be oracle+cx_oracle.
Using IAM roles to authenticate to an AWS RDS SQL tracker store
New in 3.14You can use IAM authentication to connect to an AWS RDS database without needing to provide a username
and password.
IAM_CLOUD_PROVIDER: Set this toaws.AWS_DEFAULT_REGION: Set this to the AWS region where your RDS database is located.RDS_SQL_DB_AWS_IAM_ENABLED: Set this totrueto enable IAM authentication for RDS connections.SQL_TRACKER_STORE_SSL_MODE: Set this to the desired SSL mode for the connection (Check your deployed SQL database documentation for supported values. For example: see PostgreSQL SSL Mode descriptions).SQL_TRACKER_STORE_SSL_ROOT_CERTIFICATE: (Optional) Set this to the path of the CA certificate to use for SSL verification if usingverify-caorverify-fullSSL modes. This can be downloaded for the particular region from here.
endpoints.yml to use the IAM authentication by omitting the password
field in the tracker_store configuration:
endpoints.yml
User-Scoped Querying
TheSQLTrackerStore implements user-scoped tracker querying through a dedicated users table that maps sender_id to user_id along with the timestamp when the conversation was started.
Load test your SQL database with a realistic volume of conversations and users to ensure that the user-scoped querying performs well under expected production loads. Monitor query performance and optimize indices as needed based on your specific usage patterns.
Implementation Details
- Users Table: A separate
userstable is created with columns forsender_id(mapped touser_id) andconversation_started_timestamp. The table uses dialect-specific upsert operations for PostgreSQL and sqlite and a generic approach (update followed by insert if needed) for other SQL databases to maintain compatibility. - Bulk Retrieval: User-scoped queries use two bulk operations: a paginated
userstable query to retrievesender_ids for the givenuser_id, followed by a singleevents WHERE sender_id IN (...)fetch to load all events for those conversations. This ensures query count stays constant regardless of conversation volume. - Database-Level Ordering and Pagination: The
sender_ids are ordered byconversation_started_timestampand paginated using SQLLIMIT/OFFSETclauses for optimal performance. - Automatic Cleanup: When a conversation is deleted, the corresponding entry in the users table is automatically cleaned up to maintain referential integrity.
- Efficient Indexing: Appropriate indices are created on the
userstable for all fields to optimize query performance for user-scoped lookups.
RedisTrackerStore
You can store your assistant’s conversation history in Redis by using theRedisTrackerStore.
Redis is a fast in-memory key-value store which can optionally also persist data.
High Availability Support
New in 3.14Redis high availability support is now available for the
RedisTrackerStore.
You can now deploy with Redis Cluster for horizontal scaling or Redis Sentinel for automatic failover.RedisTrackerStore now supports Redis high availability deployments through Redis Cluster and
Redis Sentinel modes, enabling enterprise-grade scalability and reliability for production deployments.
The supported deployments are:
- Redis Cluster Mode: Provides horizontal scaling and is compatible with cloud-hosted Redis services.
- Redis Sentinel Mode: Offers high availability through automatic master/slave failover.
- Standard Mode: Maintains backward compatibility with existing single-instance deployments.
Configuration
To set up Rasa with Redis the following steps are required:- Add required configuration to your
endpoints.yml:
endpoints.yml
- To start the Rasa server using your SQL backend,
add the
--endpointsflag, e.g.:
Configuration Parameters
-
url(default:localhost): The url of your redis instance -
port(default:6379): The port which redis is running on -
db(default:0): The number of your redis database. Ignored in cluster mode as Redis Cluster always uses database 0 -
key_prefix(default:None): The prefix to prepend to tracker store keys. Must be alphanumeric -
username(default:None): Username used for authentication -
password(default:None): Password used for authentication (Noneequals no authentication) -
record_exp(default:None): Record expiry in seconds -
use_ssl(default:False): whether or not to use SSL for transit encryption -
deployment_mode(default:standard): Deployment mode of Redis. One ofstandard,cluster, orsentinel. -
endpoints(default:None): List of Redis cluster node addresses in the formathost:port. Used for cluster and sentinel modes. For cluster mode, these are cluster node endpoints. For sentinel mode, these are sentinel instance endpoints. -
sentinel_service(default:mymaster): Name of the Redis sentinel service. Only used in sentinel mode.
Deployment Mode Details
- Standard Mode: Connects to a single Redis instance using url and port parameters.
- Cluster Mode: Connects to a Redis Cluster for horizontal scaling. If endpoints is not provided, falls back to auto-discovery using url and port.
- Sentinel Mode: Connects to Redis Sentinel for high availability with automatic master/slave failover.
Choosing a Deployment Mode
- Use standard mode for simple deployments with a single Redis instance.
- Use cluster mode for horizontal scaling and when using cloud Redis services that require cluster mode.
- Use sentinel mode for high availability with master/slave replication and automatic failover.
Using IAM to authenticate to AWS ElastiCache for Redis
New in 3.14You can use IAM authentication to connect to AWS ElastiCache for Redis without needing to provide static credentials.
IAM_CLOUD_PROVIDER: Set this toaws.AWS_DEFAULT_REGION: Set this to the AWS region where your ElastiCache cluster or replication group is located.AWS_ELASTICACHE_CLUSTER_NAME: Set this to the name of your ElastiCache cluster or replication group.ELASTICACHE_REDIS_AWS_IAM_ENABLED: Set this totrueto enable IAM authentication for ElastiCache connections.
endpoints.yml file to not use a username and password:
endpoints.yml
User-Scoped Querying
TheRedisTrackerStore implements user-scoped tracker querying through a secondary index that enables O(1) lookup of all conversations for a specific user.
Implementation Details
- Secondary Index: A Redis Sorted Set is maintained with the key pattern
user_trackers:{user_id}. This index stores all conversation IDs (sender_ids) for each user, enabling efficient O(1) lookup. - Batch Operations: When retrieving multiple conversations for a user, the tracker store uses Redis
MGET(multi-get) operations to fetch all tracker data in a single batch, reducing network round trips. - Index Cleanup: When a conversation is deleted, the corresponding entry is removed from the user’s sorted-set index. Orphaned index entries (entries whose tracker key no longer exists in Redis) are pruned in a single batched
ZREMcall rather than one call per orphan.
MongoTrackerStore
You can store your assistant’s conversation history in MongoDB using theMongoTrackerStore.
MongoDB is a free and open-source cross-platform document-oriented NoSQL database.
Configuration
- Add required configuration to your
endpoints.yml:
endpoints.yml
mongodb://localhost:27017/?ssl=true.
- To start the Rasa server using your configured MongoDB instance,
add the
--endpointsflag, for example:
Configuration Parameters
url(default:mongodb://localhost:27017): URL of your MongoDBdb(default:rasa): The database name which should be usedusername(default:0): The username which is used for authenticationpassword(default:None): The password which is used for authenticationauth_source(default:admin): database name associated with the user’s credentials.collection(default:conversations): The collection name which is used to store the conversations
User-Scoped Querying
TheMongoTrackerStore implements user-scoped querying through MongoDB indices and aggregation pipelines for efficient querying and ordering.
Implementation Details
- Database Indices: The tracker store creates indices on
user_idand a compound index on(conversation_started_timestamp, sender_id)to optimize query performance. - Aggregation Pipeline: User-scoped queries use MongoDB aggregation pipelines to efficiently filter, sort, and paginate conversations. This allows for complex queries with ordering and pagination at the database level.
- User ID Restoration: The implementation ensures that
user_idis properly restored from stored tracker data, maintaining data consistency across conversation sessions.
DynamoTrackerStore
You can store your assistant’s conversation history in DynamoDB by using aDynamoTrackerStore.
DynamoDB is a hosted NoSQL database offered by Amazon Web Services (AWS).
Configuration
- Add required configuration to your
endpoints.yml:
endpoints.yml
- To start the Rasa server using your configured
DynamoDBinstance, add the--endpointsflag, e.g.:
Configuration Parameters
table_name(default:states): name of the DynamoDB tableregion(default:us-east-1): name of the region associated with the client
In case the table with
table_name does not exist, Rasa will create it for you when run with single sanic worker.In case Rasa is run with multiple sanic workers, the table should be created before running Rasa. If it’s not found,
an error will be logged and an exception will be raised.User-Scoped Querying
TheDynamoTrackerStore implements user-scoped querying through DynamoDB Global Secondary Indexes (GSI).
Implementation Details
- Metadata Persistence: The tracker store saves both
user_idandconversation_started_timestamp(stored as Decimal type) in theupdate_itemdb operation when saving trackers. - Global Secondary Index (GSI): A GSI named
user_id-indexis created withuser_idas the partition key andconversation_started_timestampas the sort key. - Full-Scan Fallback: If the GSI is not available or not yet created, the implementation falls back to a full table scan which uses a filter expression by
user_id.
Ensure the GSI is created before running the Rasa Pro server. The GSI creation may take some time depending on the size of your table.
Load test your DynamoDB setup to ensure that the GSI is properly utilized for user-scoped queries and that performance meets your requirements.
Custom Tracker Store
If you need a tracker store which is not available out of the box, you can implement your own. This is done by extending the base classTrackerStore and one of the provided mixin classes that implement the
serialise_tracker method: SerializedTrackerAsText or SerializedTrackerAsDict.
To write a custom tracker store, extend the TrackerStore base class. Your constructor has to
provide a parameter host.
The constructor also needs to make a super call to the base class TrackerStore using domain and event_broker arguments:
save: saves the conversation to the tracker store. Must respect the following signature:
update: updates an existing tracker in the store (e.g. after anonymization or when retaining events during deletion). When supported, this allows a single atomic write instead of delete-then-save. The PII anonymization and deletion jobs use this method (deletion only when events need to be retained). Must respect the following signature:
retrieve: retrieves tracker for the latest conversation session. Must respect the following signature:
keys: returns the set of values for the tracker store’s primary key. Must respect the following signature:
delete: deletes the conversation corresponding to the givensender_idin the tracker store. Must respect the following signature:
get_serialized_trackers_by_user_id: retrieves serialized event dicts for all conversations belonging to a specific user, with pagination and ordering support. This method powers theGET /users/{user_id}/trackersendpoint and returns data directly from storage without replaying events throughDialogueStateTracker. Must respect the following signature:
TrackerStore parent class:
_sort_key_serialized(self, tracker_dict: Dict[str, Any]) -> Tuple[float, str]: Returns a tuple of(conversation_started_timestamp, sender_id)for sorting trackers._apply_pagination_serialized(self, trackers: List[Dict[str, Any]], skip: Optional[int], limit: Optional[int]) -> List[Dict[str, Any]]: Applies pagination to a list of serialized trackers usingskip(offset) andlimitparameters.
Configuration
Put the module path to your custom tracker store and the parameters you require in yourendpoints.yml:
endpoints.yml
Fallback Tracker Store
In case the primary tracker store configured inendpoints.yml becomes unavailable, the Rasa agent will issue an
error message and fall back on the InMemoryTrackerStore implementation. A new dialogue session will be started for
each turn, which will be saved separately in the InMemoryTrackerStore fallback.
As soon as the primary tracker store comes back up, it will replace the fallback tracker store and save the
conversation from this point going forward. However, note that any previous states saved in the InMemoryTrackerStore
fallback will be lost.