2.2.0 made a multi-tenant collection expressible: isTenant on a keyword or uuid index tells Qdrant to
colocate one tenant's points on disk, which is the layout that makes tenant-filtered search fast. What
it did not do is show that it works, and multi-tenancy is the one architecture where the difference
between the layout being right and being nearly right is a factor rather than a percentage.
Qdrant's 2026 roadmap names fully scalable multitenancy as one of three enterprise themes, which means
the server side of this is moving and a client that has never measured it will not notice when it does.
What is missing is a measurement, not a feature. Two collections with the same data, one with a tenant
index and one without, the same filtered search over both, and the numbers side by side. If the
difference is small at the size a benchmark can reach, that is worth publishing too: it tells a reader
the layout matters at a scale they can then ask about, rather than letting them assume it matters at
theirs.
The second half is the part a client can get wrong on its own. A tenant-scoped deployment usually pairs
the index with a JWT carrying a payload filter, which 2.1.0 supports, and with one collection rather
than one per tenant. Whether Kdrant's ergonomics make that pleasant is a question nobody has asked:
every search in a multi-tenant application carries the same must clause, and repeating it by hand in
every call site is how one of them ends up missing.
Exit criterion: a published benchmark compares filtered search over a tenant-indexed collection with the
same search over a plain one at a stated size, and the repository shows the shape a multi-tenant caller
should use, either as a documented pattern or as an ergonomic addition with an argument for why it needs
one.
2.2.0made a multi-tenant collection expressible:isTenanton a keyword or uuid index tells Qdrant tocolocate one tenant's points on disk, which is the layout that makes tenant-filtered search fast. What
it did not do is show that it works, and multi-tenancy is the one architecture where the difference
between the layout being right and being nearly right is a factor rather than a percentage.
Qdrant's 2026 roadmap names fully scalable multitenancy as one of three enterprise themes, which means
the server side of this is moving and a client that has never measured it will not notice when it does.
What is missing is a measurement, not a feature. Two collections with the same data, one with a tenant
index and one without, the same filtered search over both, and the numbers side by side. If the
difference is small at the size a benchmark can reach, that is worth publishing too: it tells a reader
the layout matters at a scale they can then ask about, rather than letting them assume it matters at
theirs.
The second half is the part a client can get wrong on its own. A tenant-scoped deployment usually pairs
the index with a JWT carrying a payload filter, which
2.1.0supports, and with one collection ratherthan one per tenant. Whether Kdrant's ergonomics make that pleasant is a question nobody has asked:
every search in a multi-tenant application carries the same
mustclause, and repeating it by hand inevery call site is how one of them ends up missing.
Exit criterion: a published benchmark compares filtered search over a tenant-indexed collection with the
same search over a plain one at a stated size, and the repository shows the shape a multi-tenant caller
should use, either as a documented pattern or as an ergonomic addition with an argument for why it needs
one.