Asset Browser: scalable design for large libraries

I maintain a large Blender asset library and I’ve run into a serious limitation in how Asset Browser currently handles big collections.

My setup

I keep assets organized by vendor at the file system level (each vendor has its own folder: Kitbash, Evermotion, 3Dtudor, etc.).

All these vendor folders live under one root folder (my asset library).

I use the single blender_assets.cats.txt at the root level, so all catalogs are defined once and apply recursively across every vendor’s .blend files.

This gives me exactly what I want: one clean vendor-based folder structure in my OS, and one unified catalog tree inside Blender.

The problem

Since this is technically one giant library, Blender tries to load/parse metadata from every .blend in that root library.

The bigger the collection, the more memory usage and slowdowns I get, even when I’m only previewing assets.

The result: memory quickly gets bloated, which defeats the whole point of having a unified library.

Why this matters

Vendor-based folder structures are a natural way to organize assets (easy to update or reinstall packs).

One unified library with catalogs is also the most natural way to browse assets.

Right now, these two good practices combined make Blender run out of memory for big libraries.

Proposed solution

A database-backed index for asset libraries, so Blender doesn’t need to parse everything each time.

Or at minimum: lazy loading — show me the catalog + preview instantly, but only load the heavy mesh/material data when I actually drag it into the scene.

TL;DR

With one root library covering many vendor folders, Asset Browser eats huge amounts of memory. We need a system where Blender only loads metadata + previews upfront, and only loads full asset data on demand.

This would allow large vendor-based libraries to scale, without losing the unified catalog experience.