Resources · n8n integration

n8n Postgres Chat Memory nodeConfigure Postgres Chat Memory in n8n.

An AI agent forgets everything between two messages unless something stores the conversation. The n8n Postgres Chat Memory node writes that history to a Postgres table and reads it back on the next run. Two parameters to set, one port to plug into, and the table is created for you.

Try the Postgres Chat Memory node on n8nSee the 2 parameters

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Postgres Chat Memory node actually do?

Postgres Chat Memory is a sub-node, meaning a node that never runs on its own and has no main input. You attach it to the memory port of a root node such as an AI Agent, and every exchange of the conversation then lands in a Postgres table. On the next message, the agent reads that table back instead of starting from nothing. Memory, in an AI context, is simply the message context a tool keeps between interactions.

Take a customer support assistant answering on a messaging channel. Without memory, a shopper who writes "and in blue?" gets a blank stare, because the agent has no idea what "it" was. Plug this sub-node into the AI Agent memory port, point Table Name at a table of your choice, and the thread holds together across messages, days and workflow restarts.

The second case is a shared assistant used by many people at once. Every conversation needs its own bucket, which is what Session ID decides: either the sub-node picks up the sessionId field coming from a directly connected Chat Trigger, or you write an expression such as {{ $json.userId }} to build the key yourself. Two people chatting at the same time, two session keys, two histories that never bleed into each other.

The third one is an internal data agent. You wire a chat model from OpenAI or Anthropic to the agent, give it a couple of tools that query your own APIs, and keep the history in Postgres so a colleague can ask a follow-up question an hour later and still be understood. The same sub-node also serves an AI Agent Tool when the agent itself is called by another workflow.

When would you reach for something else? If the goal is to read, edit or wipe stored messages rather than just accumulate them, that job belongs to the Chat Memory Manager root node, not to a memory sub-node. And if your workflow uses an AI chain rather than an agent, memory is not an option at all: n8n agent nodes can use memory, chains cannot.

Two limits worth knowing before you build. First, several Postgres Chat Memory nodes in one workflow share the same memory instance by default, so a destructive action in one place can overwrite what another node stored; different session IDs keep them apart. Second, the node exposes 2 head parameters at version 1 and nothing more, so anything fancier than storing and replaying a thread has to happen around it. The n8n training walks through that kind of assembly if agents are new territory.

Connect

What do you need before the node will run?

  1. 01

    Create the Postgres credential

    Open the Credentials menu in n8n and add a Postgres credential. It asks for a Host, a Database name, a User and a Password, plus a Port, an SSL mode and, only if the database sits behind one, an SSH Tunnel. The same credential then serves every workflow on the instance, on n8n Cloud or self-hosted. You create it once, you select it in the node, and never paste connection details again.

  2. 02

    Attach the sub-node to a memory port

    This node has no main input, so dropping it on the canvas alone does nothing. Drag its connector to the memory port of a root node that accepts it: AI Agent, AI Agent Tool, Chat Memory Manager or Chat Trigger. The link is what tells n8n which conversation the table belongs to. Until that connection exists the sub-node stays idle, and the agent keeps answering each message as if it were the first one.

  3. 03

    Set the table and the session key

    Fill Table Name with the table that will hold the chat history. If it does not exist yet, n8n creates it, so a fresh name is a perfectly valid answer on a first run. Then choose how Session ID is built: fromInput to reuse the sessionId field arriving from a directly connected Chat Trigger, or customKey to define the value yourself with an expression or static text.

Connections

Where does this sub-node plug in?

n8n AI workflows are built as a root node that receives the items, surrounded by sub-nodes clipped onto its ports, one type of sub-node per port.

Output (what it plugs into)

  • Memoryai_memory
01MemoryPostgres Chat Memory exposes a single memory output and that is the only place it belongs. The root node you connect it to decides which conversation gets persisted.

Postgres Chat Memory exposes a single memory output and that is the only place it belongs. The root node you connect it to decides which conversation gets persisted.

Key parameters

  • Optional: a root node runs without memory, it simply answers each message with no recollection of the previous one.
  • AI Agent and AI Agent Tool: the usual hosts, for an assistant that holds a thread across turns.
  • Chat Memory Manager and Chat Trigger: the other two root nodes that accept this port.
Use cases
a support agent that remembers an order number quoted three messages earlier, without you resending the whole transcript on every call.
Parameters

Which parameters do you actually set?

The Postgres Chat Memory node has 2 parameters. For each one: the node as you configure it in n8n, what the parameter changes, and our field notes.

01

Session ID

sessionIdType

What you see in n8n

Notes & use cases

This parameter answers one question: under which key is this conversation filed? Get it wrong and two users share a history, or the same person starts over at every message.

Key parameters

  • Connected Chat Trigger Node (fromInput): looks for an input field called sessionId coming from a directly connected Chat Trigger.
  • Define below (customKey): use an expression to reference data in previous nodes, or enter static text.
  • Key (sessionKey): the key used to store the session ID in the memory.
Use cases
a chatbot serving a whole team, where {{ $json.userId }} gives each person a private thread.
02

Table Name

tableName

What you see in n8n

Notes & use cases

Here you name the Postgres table that holds the chat history. Nothing to prepare on the database side: if the table does not exist, it gets created on the first run.

Key parameters

  • Table Name (tableName): the table name to store the chat history in, created automatically when missing.
Use cases
one table per assistant, so the sales bot and the support bot keep their transcripts in separate places even though they read the same database.
Need help

Need help automating Postgres Chat Memory with n8n?

A person reads every message.

FAQ

Questions people ask next

01Is the Postgres Chat Memory node included in n8n?
Yes. It ships inside the n8n AI package, @n8n/n8n-nodes-langchain, which comes with n8n itself. Nothing to install, nothing extra to pay on the n8n side, and it behaves the same on n8n Cloud and on a self-hosted instance running the Community Edition under the Sustainable Use licence. The one cost that can appear sits elsewhere: the provider of the chat model you connect to the agent bills its own API calls under its own terms, and n8n adds nothing on top. The memory node itself only talks to your Postgres database, so what it costs is whatever that database already costs you.
02What do you need for the node to work?
Two things. A Postgres credential, created once in the Credentials menu of n8n and reusable across every workflow; the node documentation points to the Postgres credential page for the authentication details. And a root node to plug into, because this is a sub-node with no main input that never runs on its own. Connect it to the memory port of an AI Agent, an AI Agent Tool, a Chat Memory Manager or a Chat Trigger. Then set Table Name and Session ID, and that is the whole setup. The table itself does not need to exist beforehand.
03What are the limits of the n8n Postgres Chat Memory node?
At version 1 the node exposes 2 head parameters, Session ID and Table Name, and that is the full surface. It stores and replays chat history, nothing else: reading, editing or overwriting stored messages is the job of the Chat Memory Manager root node. It also cannot help an AI chain, since n8n agent nodes can use memory while chains cannot. One more catch: add several Postgres Chat Memory nodes to a workflow and they all point at the same memory instance by default, so a destructive action can override what another node wrote unless each node carries its own session ID.
04What is the minimum you must connect to an AI agent?
A chat model. An agent without a model connected to it has nothing to think with, and the provider credential for that model is what unlocks it. Memory is the next thing you add, and this node is a reasonable first choice when your stack already runs Postgres, because the history survives restarts and stays in a database you control. Start simple: one root node, one chat model, this memory sub-node with Session ID left on the connected Chat Trigger option, and a table name you invent on the spot. Tools come after, once the conversation part behaves.
05n8n or Make for an AI assistant with memory?
It depends on where your data has to live. Make is hosted by Make, with no self-hosting option, and billed per operation. n8n runs on n8n Cloud or on your own servers through Docker or npm, with an identical workflow either way, which matters when chat transcripts land in a database you are responsible for. Storing history in your own Postgres instance is only possible if you can reach that instance, so a self-hosted setup changes the picture. Cost models differ too: per operation on one side, hosting on the other. Both build visually, so the choice rarely comes down to the canvas.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations