HONEYBEE: Efficient Role-based Access Control for Vector Databases via Dynamic Partitioning

TL;DR

Honeybee tackles enforcing access control in vector databases by leveraging RBAC policy structure to create overlapping partitions that replicate vectors across partitions. It combines an analytic performance model with a greedy MINLP-inspired offline partitioning strategy and a lightweight online routing mechanism to minimize average query latency under memory and recall constraints. Empirical results show Honeybee can dramatically reduce latency (up to 13.5x) with modest memory overhead (around 1.24x) compared to post-filtering, while approaching the efficiency of per-role dedicated indices with substantial memory savings (up to 90.4% less). Importantly, Honeybee complements hybrid search indexes like ACORN, achieving further speedups and providing a practical, scalable pathway to secure vector search in enterprise environments.

Abstract

Enterprise deployments of vector databases require access control policies to protect sensitive data. These systems often implement access control through hybrid vector queries that combine nearest-neighbor search with relational predicates based on user permissions. However, existing approaches face a fundamental trade-off: dedicated per-user indexes minimize query latency but incur high memory redundancy, while shared indexes with post-search filtering reduce memory overhead at the cost of increased latency. This paper introduces HONEYBEE, a dynamic partitioning framework that leverages the structure of Role-Based Access Control (RBAC) policies to create a smooth trade-off between these extremes. RBAC policies organize users into roles and assign permissions at the role level, creating a natural ``thin waist" in the permission structure that is ideal for partitioning decisions. Specifically, HONEYBEE produces overlapping partitions where vectors can be strategically replicated across different partitions to reduce query latency while controlling memory overhead. To guide these decisions, HONEYBEE develops analytical models of vector search performance and recall, and formulates partitioning as a constrained optimization problem that balances memory usage, query efficiency, and recall. Evaluations on RBAC workloads demonstrate that HONEYBEE achieves up to 13.5X lower query latency than row-level security with only a 1.24X increase in memory usage, while achieving comparable query performance to dedicated, per-role indexes with 90.4% reduction in additional memory consumption, offering a practical middle ground for secure and efficient vector search.

Figures (15)

• Figure 1: Given RBAC policies, memory and recall constraints, Honeybee optimizes for a data partitioning strategy that achieves a balanced trade-off between query latency and memory overhead.
• Figure 2: RBAC policy implemented via Row-Level Security.
• Figure 3: Overview of Honeybee's workflow. Yellow elements represent main components as well as inputs and outputs of Honeybee, while blue elements represent configurable components by administrators, such as documents, RBAC policies, index types, and constraints.
• Figure 4: Each iteration of the greedy algorithm, one or more roles are moved from the largest partition to form a new partition (green blocks). The roles are chosen greedily based on the estimate performance improvement using the analytical models.
• Figure 5: Trade-off between Query Time and Memory Usage across Permission Workloads.

Theorems & Definitions (1)

• Definition 2.1