Local DB

Local DB is ComfyUI's answer to the prompt box nobody wants to retype. It's a persistent key-value text store that lives on your machine: you save prompt snippets under named keys, then type $key anywhere in the node and it swaps in a random value from that key. No API, no key, no model download - the whole thing is a Python backend that reads and writes JSON plus a frontend that resolves your text. If you've ever wished the {this|that|the other} wildcard trick from the old A1111 days had a place to actually store its options, this is that place, minus the cloud.

What it actually does

You get a node under utils > Local DB (internally it registers as Load DB, which trips up a few people - search for "Local DB" in the Manager and you'll find it). Type into the big input field, press enter, and the node resolves two syntaxes for you:

• $key - a random value from whatever you've saved under that key.
• {a|b|c} - picks a random option, the classic wildcard bracket trick the KB calls out as "old A1111 wildcard syntax that most people arriving after 2024 never learned."

Both resolve recursively, and // and /* */ comments get stripped, so you can annotate your vault entries and never see the notes in the output. The result lands in the node's actual STRING output, ready to feed a CLIP Text Encode or any prompt-builder. The workflow pattern the community converged on applies here: batch 32 renders and get the same subject across different cameras, lighting, and moods without touching a training run.

How the storage works

This is the part people underestimate. The data isn't in ComfyUI's workflow JSON - it's plain files in custom_nodes/comfyui-local-db/db/, one <key>.json per key, each holding an array of strings. The backend exposes GET/POST /shinich39/db routes on ComfyUI's own server, and the frontend syncs through them. Every time the node loads it backs up your JSON files into a date-stamped folder, so a mistake costs you a day's history, not everything. The flip side: delete the custom node folder and you delete your vault. Back up db/ before you prune packs.

The inputs that matter

The schema is about as thin as it gets - two text inputs, one string output:

• input - the textarea you type your $key and {a|b|c} template into. This is the one you live in.
• text - hidden in the UI, but it's the real output value: whatever the parser last resolved. Your output port reads from here.
• Output text (STRING) - wire it into a CLIP Text Encode Prompt, or string-concat it into a bigger prompt.

Beyond the schema, the UI gives you a "find" key box and per-value buttons (Add, Copy, Change, Remove, Spread). Spread is the genuinely clever one: it takes a templated entry with {options} and expands it into separate concrete DB entries, so you can grow a library by writing one line.

Installing it

ComfyUI Manager: search the pack title "comfyui-local-db" and hit install. Or the manual route:

cd ComfyUI/custom_nodes
git clone https://github.com/shinich39/comfyui-local-db

Restart ComfyUI. No dependencies beyond what ComfyUI already ships, no models.

The honest gotchas

Where people get burned: this is a tiny project - a few stars, a couple of contributors, MIT licensed - and at the time of writing the upstream repo 404s on GitHub. It appears to have been taken down; the code survives in forks, so if git clone fails, clone a fork (or grab the tarball) into custom_nodes/ instead. There's also essentially zero community footprint - nobody on r/comfyui is talking about it, so don't expect tutorials. Finally, resolution happens on the frontend, debounced, so the queued value is whatever was last rendered: that's the point for variety, but it means a single node doesn't hold one fixed prompt per render if you're hunting for a reproducible batch. For a free local prompt bank with $key magic, it's a fun tool - just don't build a cathedral on it.