Skip to content
Nappai Documentation

Cassandra Chat Memory

Cassandra Chat Memory is a component that lets your Nappai dashboard keep a record of every chat message in an Apache Cassandra database. It stores each message in a table you specify and can pull them back later so your AI assistant remembers what was said before.

How it Works

When you add this component to a workflow, it first connects to your Cassandra database.

  • If you’re using AstraDB, you give it the database ID and a token.
  • If you’re using a local Cassandra cluster, you provide the contact points (host addresses), username, and password.

Once the connection is established, the component creates a CassandraChatMessageHistory object. This object knows how to write new chat messages to the table you named and how to read past messages that belong to the same session ID. The session ID lets you keep conversations separate – each ID gets its own set of messages.

The component itself does not perform any actions on the messages; it simply builds the history object that other components (like an LLM) can use.

Inputs

Input Fields

The following fields configure the database connection and where the messages are stored.

  • Contact Points: The host address(es) of your Cassandra cluster or the database ID for AstraDB.
  • Keyspace: The keyspace (or AstraDB namespace) that contains the table.
  • Table Name: The name of the table (or AstraDB collection) where chat messages will be written.
  • Session ID: A unique identifier for the conversation. All messages with the same ID are grouped together.
  • Cluster arguments: Optional dictionary of extra keyword arguments for the Cassandra cluster (e.g., SSL settings, timeout values).

Credential
This component requires a Cassandra DB credential.

  1. In Nappai, go to the Credentials section and create a new Cassandra DB credential.
  2. Enter the Cassandra database ID, username, and token.
  3. In the component, select that credential from the Credential dropdown.
    The credential fields (database ID, username, token) are not shown in the input list because they are supplied through the credential.

Outputs

  • Memory – A BaseChatMessageHistory object that can be passed to other components (e.g., an LLM) to provide conversation context.

Usage Example

  1. Drag the Cassandra Chat Memory component onto your workflow.
  2. Fill in Contact Points, Keyspace, Table Name, and Session ID.
  3. Select the Cassandra DB credential you created earlier.
  4. Connect the Memory output to the memory input of an LLM component.
  5. Run the workflow – every message the LLM sends or receives will be stored in Cassandra, and future calls will automatically load the conversation history.
ComponentWhat it does
InMemory Chat MemoryStores chat history in RAM (fast but not persistent).
Redis Chat MemoryUses Redis to keep conversation history.
SQL Chat MemoryStores messages in a relational database.
Vector Store MemoryKeeps embeddings of messages for semantic search.

Tips and Best Practices

  • Use a unique Session ID for each user or conversation to avoid mixing messages.
  • Keep the Table Name short and descriptive; it should match the table you created in Cassandra.
  • If you need SSL or custom timeouts, put those settings in Cluster arguments.
  • Regularly back up your Cassandra keyspace to protect chat history.
  • Test the component with a small dataset first to confirm the connection works before scaling.

Security Considerations

  • Store your Cassandra credentials in Nappai’s secure credential store; never hard‑code them in the workflow.
  • Use SSL/TLS when connecting to AstraDB or a remote Cassandra cluster to encrypt data in transit.
  • Restrict database permissions so the credential can only read/write the specific keyspace and table you need.