Storage & database
Nodes that set fields, query databases and keep values for later. In the palette they sit under Data Storage. All of them have one input and one output port.
Set


What: Sets, appends, increments, deletes or merges fields on each item. It is the first place to go for anything an expression can't do on its own, because expressions only look values up.
Configuration:
| Field | Notes |
|---|---|
rules |
Required. Each rule is {key, value, operation, type, condition}. |
keepExistingData |
Keep the incoming fields and add the rules' fields on top. Default on. Off: the output holds only the rules' fields. |
skipNullValues |
Don't write a rule whose value is null. Default off. |
allowOverwrite |
Default on. Off: a rule only writes a key that is not already there, which gives you a default value. |
globalTransforms |
Upper-case, lower-case or trim named fields before the rules run, for example {"lowercase": ["email"], "trim": ["name"]}. removeEmpty: true drops empty fields. |
Operations: set (default), append, prepend, increment, decrement, delete, merge.
Example: combine two branches into one item.
{
"keepExistingData": false,
"rules": [
{ "key": "users", "value": "{{ $node['Fetch Users'].output.response.body }}" },
{ "key": "orders", "value": "{{ $node['Fetch Orders'].output.response.body }}" }
]
}Later nodes read the result as {{ $node["Combine"].output.users }}.
Notes:
- Set works within a run. It does not keep values between runs. For values that don't change between runs, use workflow variables (
$workflow.variables) or workspace variables ($env); see Referencing data. - A misconfigured rule fails the node instead of being skipped.
Database
What: Runs SQL against a database: PostgreSQL, MySQL, SQLite or MongoDB.


Configuration:
| Field | Notes |
|---|---|
mode |
remote (default) or local |
connection |
The database to connect to: type (postgresql, mysql, sqlite, mongodb), host, port, database, username, password, ssl |
operation |
Required: query (default), insert, update, delete or transaction |
sql |
The statement |
parameters |
Positional parameters for the statement |
queries |
For transaction: a list of {sql, parameters} run together |
readOnly |
Only allow SELECT statements, in local mode. Default on. |
timeout |
Seconds. Default 30. |
Output: the incoming fields plus the result. A query returns rows (a list of objects), rowCount and columns.
Example:
SELECT id, total
FROM orders
WHERE customer_id = {{ $trigger.payload.customerId }}
AND status = 'paid'
ORDER BY total DESC
LIMIT 100Expressions in SQL are safe. Each {{ … }} block is sent to the database as a query parameter, not pasted into the statement, so a quote in the data can't change your query. Values in parameters keep their type: a number stays a number and null stays null.
MongoDB: sql holds the collection name, and parameters[0] holds the filter (or the document to insert). For update, parameters[1] holds the update.
Cache Storage
What: A key-value store with an optional time-to-live.
Configuration:
| Field | Notes |
|---|---|
operation |
Required: set, get, delete, clear, exists, list or increment |
key |
Cache key |
value |
For set |
ttl |
Seconds |
storage |
{type, namespace}. Use namespace to keep workflows' keys apart. |
Output: get returns found and value; exists returns exists (true or false).
Example (skip duplicate webhook deliveries):
operation: exists
key: webhook:{{ $trigger.payload.id }}Connect the result to an If node: exists is true means you've seen this event already.
Notes:
- The cache is held in memory by the Flero worker that runs the workflow. Runs on the same worker share it, but it is not shared between workers and it is emptied when the worker restarts. Use it to save time, not as a record you rely on.
- It does not use an external cache such as Redis, whatever
storage.typesays.
Contextual Memory
What: Stores and retrieves memory and preferences for AI agents.
Configuration: operation (required: store, retrieve, search, consolidate, prune, analyze, preferences, conversation, context), key, value, query, ttl, priority (low, normal default, high).
For conversation history in a chat workflow, the AI Agent's own memory setting is usually enough.
Tips & gotchas
- Database passwords are sensitive. The connection details are part of the node's configuration. Connect as a database user with only the access the workflow needs, and limit who can edit the workflow.
- Durable data belongs in a real database. Neither Set nor Cache Storage keeps data permanently.
Related
- Data transformation
- Expressions → Referencing data
- RAG nodes, for vector storage
Found something out of date? This page lives in the Flero docs content set.