LangGraph + SQLite | Chatbot with Database Integration | CampusX

The core upgrade is replacing a RAM-based “memory saver” with a SQLite-backed checkpointer so a LangGraph chatbot can keep conversations permanently. That change fixes a major reliability gap: previously, closing the app or reloading the page wiped chat history, forcing users to restart from scratch. With SQLite in place, messages and conversation state persist across restarts, letting users resume days later from the exact point they left off.

The chatbot’s earlier improvements—GUI support via Streamlit, token streaming for better user experience, and “threads” so multiple conversation histories can be resumed—remain intact. The new work targets what happens after the user refreshes or exits. Instead of storing all messages in memory, the system writes them into a database through LangGraph’s checkpointing mechanism. The result is a chatbot that can retrieve prior messages reliably and separate histories by thread ID.

Implementation starts with backend changes in the LangGraph code. A new file is created for the database-enabled backend (named in the transcript as “LangGraph Database Backend.py”). The key technical step is installing an external library called “langgraph-checkpoint-sqlite,” then swapping the checkpointer from “langgraph.checkpoint.memory” to a SQLite-based saver. Because SQLite connections are thread-sensitive, the setup includes a “check_same_thread” parameter set to False to avoid runtime errors when the workflow later uses multiple threads for concurrent conversations.

Next comes the database connection wiring: the code imports sqlite3, creates (or reuses) a local database file (shown as “lets_chatbot.db”), and passes the resulting connection into the SQLite checkpointer. After that, the rest of the chatbot invocation logic stays essentially the same—messages still go through the LangGraph chatbot, but now the checkpointing layer persists outputs.

A test confirms the behavior. Running a simple chat sequence creates the database file automatically in the project directory (“chatbot.db” in the transcript’s naming). Re-running the same prompt after the program exits shows the chatbot can answer using previously stored context, demonstrating that the conversation state survived the restart. The transcript also shows thread isolation: switching from “thread one” to “thread two” stores separate histories, and asking “what is my name” returns the correct name for each thread.

To make the persistence tangible, the database is visualized using a VS Code extension (a “SQLite Viewer” extension). The checkpointer creates multiple checkpoints per thread—checkpoint objects appear repeatedly because the workflow generates checkpoints at different stages (start, near the chat node, and end). The transcript demonstrates drilling into a specific checkpoint to view the stored messages and metadata.

Finally, the Streamlit frontend is updated so it no longer initializes with empty thread lists. Instead, it queries the backend for existing thread IDs from the SQLite checkpoint store, then populates the session state accordingly. When the UI reloads, the thread list and prior conversations reappear. The practical outcome: users can close the app, reopen it later, and still see all prior threads and messages—whether they were “Nitesh,” “Rahul,” or any other conversation thread created earlier.