Named Vectors + Multi-Tenancy: Storage behavior for null/unpopulated vectors

Hi Weaviate team,

I have a multi-tenant collection with multiple named vectors and I have a question about storage behavior:

Context:

  • I have a collection with multiple named vectors
  • Each tenant may not use all the defined named vectors
  • Some named vectors may remain unpopulated/null for certain tenants

Question:

When a named vector is defined at the collection level but is unpopulated/null for a specific tenant:

  1. Does it still consume storage space for that tenant? Or is the bucket only created when the first actual vector value is written?
  2. If the bucket is created on the first vector write — is the storage space then allocated for the entire tenant (i.e., all objects in that tenant), or only for the objects that actually have that vector populated?

I really appreciate any help you can provide.

Hey @youssef_ajlani,

Welcome back to our forum, and looking forward to seeing how you’re building with Weaviate :hugs:
Does an unpopulated named vector consume space per tenant?

Yes, a small fixed overhead. The LSM bucket is created eagerly when the tenant’s shard is activated (loaded), for every named vector defined at the collection level, regardless of whether anything is written.

Overhead per empty named vector ≈ bucket dir + manifest/WAL + one file descriptor. HNSW graph / commitlog files themselves are not written until the first vector is inserted.

Note: with LAZY_LOAD_SHARDS enabled, this cost only materializes once the tenant shard is actually activated, a COLD tenant pays nothing on disk beyond metadata.

If created on first write, is space allocated per-tenant or per-populated-object?

Per-populated-object only. The write path iterates obj.Vectors (the map of vectors present on the object), not the collection’s target-vector list.

So in a tenant with 1000 objects where only 100 populate vector_A: only those 100 pay HNSW/flat storage; the other 900 pay nothing for vector_A.

So:

  • Named vector defined, tenant shard COLD (lazy) → 0 on disk
  • Named vector defined, tenant active, zero objects populated → small fixed bucket overhead, no index files
  • Named vector defined, N of M objects populate it → cost proportional to N only

Kind regards,
Mohamed Shahin
Tech Lead - Weaviate Support
(Ireland :ireland:, UTC+00:00/+01:00)
mohamed@weaviate.io
Weaviate & LinkedIn

Thanks, @Shahin! That’s exactly what I was looking for. Really appreciate the detailed explanation!