Model DB

The name is a little misleading. Model DB isn't a database of your models - it's a database of your settings, keyed by model. The idea is simple and genuinely handy: you bounce between checkpoints all day (a photoreal one for that render, an anime one for that character), and every swap means re-typing a prompt, re-setting CFG, re-picking a sampler. Model DB remembers which settings go with which checkpoint and hands them to the sampler for you.

It's a deep-cut utility from shinich39, a small solo author who's published a handful of similarly narrow ComfyUI QoL packs. Don't expect this in any "essential nodes" list - Google has basically never heard of it. But if you're a serial checkpoint hopper, the trick is real.

How it works

Model DB is a checkpoint loader with memory. You pick your model in the required ckpt_name dropdown (it lists your installed checkpoints, same enum the stock Load Checkpoint uses), and the node spits out the loaded model plus the saved settings for that model. Change the checkpoint and the stored settings for the new one come back. It saves them with the current checkpoint as the key - and per the README's update log, the default key is now just the model's own name. There's a key input, but the author deliberately keeps keys locked to the model name to simplify the flow, so the honest answer is: leave it alone.

The "save" part isn't a button - whatever you set in the widgets is what gets remembered against that model. That's the whole loop.

What to wire where

The outputs read like the left half of a KSampler block, because that's exactly what they replace:

• MODEL, CLIP, VAE - the loaded checkpoint, straight into the KSampler (or the empty latent's conditioning).
• POSITIVE, NEGATIVE - your saved prompts.
• SEED, STEPS, CFG, DENOISE, WIDTH, HEIGHT - the numbers, all typed correctly (INT vs FLOAT) so they plug straight in.
• LATENT - a saved latent state, added in a later update. If you don't know why you'd want that, ignore it.

So one node replaces Load Checkpoint + your prompt block + the sampler settings widgets. Swap the model and everything about it follows.

The trap

Here's where people get burned. The SAMPLER_NAME and SCHEDULER outputs cannot be linked into a stock KSampler's sampler_name and scheduler inputs - that's the author's own note, not a rumor. Those two KSampler fields are dropdown menus, and vanilla ComfyUI won't take a plain STRING wire for them. So your saved sampler/scheduler choices are recorded but effectively read-only: you'll be setting them by hand on the KSampler to match. It's a little silly, but it's a ComfyUI input-type limitation, not a bug in this node. If you expected a fully automated sampler swap, that's the asterisk.

Installing it

Install via ComfyUI Manager (search "comfyui-model-db" or "Model DB"), or manually:

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

Then restart ComfyUI and add utils > Model DB. No model downloads, no heavy dependencies, no requirements.txt to fight - it just uses checkpoints you already have. That's the nicest thing about it.

One honest caveat: as of writing, the GitHub repo 404s (it may have gone private or been taken down). If a git clone prompts you for a username instead of cloning, that's why - try Manager first, and don't build a mission-critical workflow on a pack this small and quiet. There's zero community signal about it to lean on, which is its own signal about how obscure it is.

Verdict

It's a 4-impressions-on-Google niche node, so temper expectations. If you only run one or two models, this solves a problem you don't have. If you swap checkpoints constantly and are tired of re-typing the same ten settings, Model DB is a tidy little quality-of-life hack that costs nothing to try. Just remember the sampler caveat and don't expect updates.