WanVideo Embedding Database
The hidden DuckDB that's been quietly logging every experiment you run
- report
Every vector node in this pack - the difference, arithmetic, interpolation, analyzer, even the noise controller - silently stores its embeddings and operations in a DuckDB database. Most of the time you'll never notice, which is by design. This node is the way to actually look at what's accumulating, and to keep the thing from turning into a landfill.
It lives at ~/ComfyUI/models/wan_embeddings/embeddings.duckdb, auto-created on first use. Embeds are compressed with zstandard (the pack advertises 3–4×), deduplicated by prompt hash, and every vector operation gets logged with its inputs, weights, execution time, and peak memory. It's a genuinely thoughtful little data layer - the author's 20-year data background shows here - and it exists so that your block-mapping experiments leave a queryable paper trail instead of vanishing into the void.
The three actions
- stats (default) - total embeddings, total operations, storage size, average compression ratio, and per-operation-type breakdown (count, avg time, avg memory). The "how much have I logged and is it costing me anything" readout.
- list_recent - the last 10 stored embeddings with prompt, creation time, access count, and compression ratio. Great for remembering what you've actually tested.
- cleanup - purges embeddings older than
cleanup_days(default 30) and accessed fewer thancleanup_min_accesstimes (default 5). The "archive the experiments, keep the data points that keep getting reused" filter. Both knobs are required inputs, so set them deliberately.
Output is a single report STRING. It's a management node - nothing flows through it.
Why you'd bother
Two honest reasons. First: the database is the pack's community-research angle. The README says plainly that DuckDB is bundled for your own testing and to facilitate sharing data for open-source research into "which blocks do what." If you're running those experiments, stats and list_recent are how you check your data is accumulating correctly, and cleanup keeps the dataset tidy.
Second, and more immediately useful: disk. Every vector op and every analyzer run writes an entry. If you've been churning experiments for weeks, that DuckDB file grows, and cleanup with a sensible cleanup_days/cleanup_min_access is the maintenance you'd otherwise forget. That's the whole job.
Install & gotchas
Same pack, WanVideoWrapper first:
cd ComfyUI/custom_nodes
git clone https://github.com/kijai/ComfyUI-WanVideoWrapper # required first
git clone https://github.com/fblissjr/ComfyUI-WanActivationEditor
cd ComfyUI-WanActivationEditor && pip install -r requirements.txt
Restart ComfyUI (ComfyUI Manager: search "ComfyUI-WanActivationEditor"). duckdb and zstandard are in requirements.txt - they auto-install, but if you installed the pack manually and skipped pip install -r requirements.txt, the database silently won't initialize and every node that touches it will error. That's the most common failure mode here, and it's also the easiest to fix. The DB is a real DuckDB file, so if you ever outgrow the node, duckdb CLI / Python can query it directly - the schema (embeddings, vector_operations, operation_inputs) is right there in database.py.
Inputs (3)
| Name | Type | Default | Description |
|---|---|---|---|
| action | COMBO | stats | 3 options: stats, cleanup, list_recent |
| cleanup_days | INT | 301–365 | — |
| cleanup_min_access | INT | 51–100 | — |
Outputs (1)
| Name | Type | Description |
|---|---|---|
| report | STRING | — |