How would you offer per-tenant usage metrics (storage, query volume) in a shared multitenant Qdrant deployment?

Qdrant does not natively bill or meter per tenant, so the metrics must be built at the application level. Storage metrics come from counting the points and the payload size per tenant: since every point carries a tenant_id, you can count points per tenant by iterating over the collection or by maintaining a running count as points are upserted. Payload size is harder because Qdrant does not report per-point payload bytes directly; the common approach is to estimate from the payload schema and the average payload size, or to maintain a per-tenant byte counter in the application as points are written. Query volume comes from logging every query with its tenant_id and aggregating the logs. The application-level metering has the advantage of being flexible - you can define whatever metrics matter to the business - and the disadvantage of being separate from the database, so it must be kept in sync and it can drift if not carefully maintained.

The mechanism has three parts: counting, logging, and aggregating. Counting storage: on every upsert, increment a per-tenant counter by the size of the point (vector bytes plus payload bytes); on every delete, decrement. This gives a real-time estimate of storage per tenant. Alternatively, periodically scan the collection and count points per tenant using the payload index - this is accurate but expensive for large collections. Logging queries: every query goes through the trusted service that enforces the tenant filter, so the service can log the tenant_id, the query type, the latency, and the result count. Aggregating: a batch job or a stream processor aggregates the logs into per-tenant metrics (queries per hour, p99 latency, error rate) and stores them in a metrics store. The metrics can then be exposed in a dashboard or used for billing. The key requirement is that every query and every write goes through the trusted service, so there is a single place where the metering happens. If clients can talk to Qdrant directly, the metering will be incomplete and can be bypassed.

The trade-off is between accuracy and cost. Real-time per-tenant metering with counters is cheap but can drift; periodic reconciliation with a full scan is accurate but expensive. The right approach depends on how accurate the metrics need to be - for billing, they must be accurate and reconcilable; for dashboards, an estimate may be sufficient. The common mistake is to rely on Qdrant's collection-level metrics, which are not per-tenant. The second mistake is to not log queries, so query volume is unknown. The third mistake is to let clients bypass the trusted service, so the metering is incomplete. The fourth mistake is to not reconcile the counters, so the storage numbers drift over time. The fifth mistake is to meter only successful queries and not errors, so the error rate per tenant is invisible. Version note: Qdrant's metrics and the collection info API have evolved, but they are collection-level, not tenant-level. The per-tenant metering must be built in the application. The payload index on tenant_id enables efficient counting if you choose to scan periodically.

Version-dependent: Qdrant's collection info and metrics APIs have evolved across releases, but they remain collection-level. Per-tenant metering must be built in the application. The scroll API and the payload index on tenant_id are the tools for reconciliation, and their API shapes have changed with the query_points API in qdrant-client 1.10+.