Transient vs Persistent Collections: Which to Use

A practical guide to choosing between a Transient collection that lives for a single run and a persistent collection that any workflow can read for the long term.

Overview

When you use a Knowledge node in Spojit, you embed documents into a collection and then query that collection with AI. The collection is where the chunked, searchable form of your documents lives. Spojit gives you two kinds of collection to embed into: a Transient collection that Spojit creates automatically for one run and cleans up when the run finishes, or a persistent collection that you create ahead of time and keep around for as long as you need it. Picking the right one keeps your workflows simple and your storage tidy.

The mental model is straightforward. A Transient collection is scratch space: it exists only for the workflow run that creates it, it is shared by every node in that same run, and it is discarded on completion so nothing accumulates. A persistent collection is an archive: it is workspace-scoped, so any workflow in your workspace can query it, and it stays put until you delete it. If a document matters only for the decision you are making right now, reach for Transient. If you are building a library that many runs and many workflows will read over time, build a persistent collection.

What a Transient Collection Is

You select a Transient collection by choosing Transient in the Collection dropdown of a Knowledge node, in either Embed mode or Query mode. There is nothing to set up first. Spojit creates the collection on the fly for that run, so you do not provide a File Name and you do not pick an Embedding Model for it. Every Knowledge node in the same run that points at Transient reads and writes the same scratch collection, so you can embed in one node and query in a later node within that run. When the run completes, Spojit removes the collection automatically.

This makes Transient ideal for the one-off embed, query, discard pattern: you receive a single document, embed it, ask AI a few questions about it, and you never need it again. A common example is extracting fields from a single invoice or purchase order that arrived in this run. You are not building a reusable reference set, so there is no reason to keep the embedded chunks around afterward.

What a Persistent Collection Is

A persistent collection is one you create and name in the Knowledge section of the sidebar with New Collection. You give it a name, an optional description, and the embedding model is fixed at creation. You can open it to Upload Document manually, watch documents move from PROCESSING to READY, and see each document's chunk count in the document table. Because collections are workspace-scoped, any workflow in your workspace can point a Knowledge node in Query mode at it. That is what makes it an archive: many workflows read it, and the documents survive across runs until you delete them.

Choose a persistent collection when the knowledge has lasting value: a product catalog, company policies, an FAQ, a manual, or a growing index of documents that arrive over time. You embed into it once (or keep adding to it), and then any number of workflows query it whenever they need an answer. To build a persistent collection workflow side, point an Embed mode Knowledge node at the named collection and provide a File Name, which overwrites if a document with that name already exists.

How to Decide

Lifespan. If the document is only relevant to the run you are in, use Transient. If it should still be queryable next week, use a persistent collection.
Audience. If only the nodes in this one run need to read the content, use Transient. If other workflows in your workspace need to query it, use a persistent collection.
Cleanup. If you do not want embedded chunks accumulating, Transient auto-cleans on completion. If you want a managed archive you can review and prune yourself, use a persistent collection.
Setup cost. Transient needs no collection created in advance and no File Name. A persistent collection requires you to create it first and name each document.

The Embed, Query, Discard Pattern

The clearest use of a Transient collection is processing a single document inside one run. A typical shape looks like this:

An upstream node produces the document bytes. For example, an Attachment node in a Mailhook workflow exposes a PDF as {{ attachment.content }} (base64), or an FTP connector node returns a file you reference as {{ sftp_result.data.content }}.
A Knowledge node in Embed mode with Collection set to Transient, the right Document Type (for example PDF), and Document Input set to that base64 reference. No File Name is needed.
A later Knowledge node in Query mode, also set to Transient, with a natural-language Prompt such as asking for the invoice total and line items, an optional Response Schema to force structured JSON, and an Output Variable you reference downstream.
The run finishes and Spojit discards the Transient collection. Nothing to clean up, nothing left behind.

You can scaffold this quickly by asking Miraxa, the intelligent layer across your automation, to build it for you, then fine-tune each node in the properties panel. A specific prompt such as "Add a Knowledge node in Embed mode using a Transient collection that embeds {{ attachment.content }} as a PDF, then a Knowledge node in Query mode on the same Transient collection that extracts the invoice total" gives Miraxa enough to lay out the nodes accurately.

Tips

Within one run, every Knowledge node set to Transient shares the same collection, so embed first and query afterward in the same execution to read what you just embedded.
For a persistent collection, always query with the same embedding model the collection was created with. The model is fixed at creation, so embed and query stay aligned automatically when you point at the named collection.
When you embed into a persistent collection, give each document a stable File Name. Re-embedding with the same name overwrites the existing document, which is handy for refreshing a policy or catalog file in place.
Use a persistent collection's document table to confirm documents reach READY before another workflow queries them, since a document still in PROCESSING will not return results yet.

Common Pitfalls

Expecting a Transient collection to survive the run. It does not. If a later, separate run needs the same content, embed it into a persistent collection instead.
Trying to query a Transient collection from a different workflow. Transient is scoped to the single run that created it and is never visible elsewhere. Cross-workflow reads require a persistent collection.
Putting a File Name or embedding model into a Transient embed and expecting it to matter. Transient skips both. Provide them only when embedding into a named, persistent collection.
Re-embedding the same large reference set into a Transient collection on every run when the content rarely changes. That repeats work each execution. Embed it once into a persistent collection and query that instead.