save SQL memory

comfyui_LLM_party (people mostly just call it "LLM Party") is a sprawling node pack that turns ComfyUI's graph into a place to build actual LLM agents - tool calling, personas, RAG knowledge bases, dialog loops, the works. save_SQL_memo is its answer to a problem every chatbot eventually hits: where does the conversation history actually live? By default that's usually a local file tied to one machine. This node writes it into a proper SQL database instead.

Give it a chunk of conversation history and an ID, and it upserts that history into whatever database sits behind database_url. The default value shown on the node - postgresql://myuser:mypassword@localhost:5432/mydatabase - tells you the intended target: Postgres. It's an output node, meaning it's meant to sit at the end of a chain and just do its job (write the row) rather than feed something further downstream in the same run.

Inputs and outputs that matter

• history - the conversation text you want persisted. In a typical LLM Party graph this is the accumulated transcript coming out of a dialog/agent loop, not a single message.
• history_id - an integer key identifying which conversation row this write belongs to. This is what lets you look the same conversation back up later.
• database_url - your connection string. Swap the placeholder credentials for a real, reachable Postgres instance.

The single output is history_id, echoed back so you can chain it into whatever comes next - a log node, a condition, or just confirmation that the write targeted the row you expected.

Why bother with a database

The obvious case is persistence across restarts: a flat memory file tied to one ComfyUI install disappears the moment you rebuild the environment or move to a different machine. A SQL row doesn't. The less obvious case is that once history lives in Postgres, anything else - a web app, a dashboard, a second workflow - can read the same conversation by querying history_id directly, without going through ComfyUI at all. That's the real reason a node like this exists in an agent-building pack: it turns "memory" from a ComfyUI-local concept into a shared, queryable one.

Installing it

Search comfyui_LLM_party in ComfyUI Manager and install, or do it by hand:

cd ComfyUI/custom_nodes
git clone https://github.com/heshengtao/comfyui_LLM_party

Then, inside your ComfyUI Python environment, pip install -r requirements.txt from the pack's folder - this is a big all-in-one project (LLM APIs, local model loading, RAG, TTS, and a long tail of tool nodes), so the dependency list is heavier than a typical single-purpose pack. If you only want the API-calling side and not local/GGUF model support, the README points to a slimmer only_api branch. Restart ComfyUI after either method, and make sure you don't end up with two comfyui_LLM_party folders in custom_nodes - that's a real way people get "node not loading" errors with this pack.

Common issues

The connection string is the thing to get right. localhost in the default value only works if your database is running on the exact same machine as the ComfyUI process - if you're on a remote box or a cloud GPU, you need the database's actual reachable host, and the DB has to accept connections from wherever the executor lives (firewall/security-group rules, not just the connection string). Beyond that, this node assumes the database and its Python driver are already sorted; if the write fails outright, check that first before assuming the node itself is broken. And because this pack pulls in a lot of dependencies at once, a pip install -r requirements.txt that half-completes is a common source of mysterious import errors - if save_SQL_memo doesn't even show up in the node list, re-run the install and read the pip output for errors rather than assuming it's a ComfyUI problem.