From prototype to production: High QPS for Databricks AI Search
Databricks AI Search now supports high-QPS scaling up to thousands of queries per second via a single parameter, eliminating manual infrastructure management for production workloads.
The useful question is what changes for users, developers or buyers, and whether the announcement stays industry context or becomes something people can actually use.
Search workloads at consumer scale often require thousands of queries per second, with peak traffic far exceeding average rates. Historically, achieving production-level QPS meant building custom retrieval stacks, manually sizing capacity, and managing load balancers for each use case. This process repeated for every new search application, adding operational complexity across vector databases, search engines, and DIY solutions. Databricks AI Search previously required this manual effort to scale prototypes into production environments.
The new high-QPS scaling feature for Databricks AI Search is now generally available, allowing users to set a target QPS via a single parameter. This target can be configured at endpoint creation or adjusted on existing endpoints through the SDK, REST API, or UI. Databricks automatically provisions the necessary infrastructure to meet the specified QPS without requiring users to manage replicas, nodes, or load balancers. Unity Catalog governance and Delta Sync remain fully supported, enabling seamless scaling from prototype to production within the same platform.
Three common production patterns benefit from high-QPS scaling: search bars in e-commerce or streaming platforms, recommendation systems that fire queries per page view, and real-time entity resolution for identity matching or deduplication. For search bars, keystroke-level queries can generate rapid spikes in QPS, directly impacting conversion rates. Recommendation systems face similar traffic surges with every page view, while entity resolution requires consistent performance to meet operational SLAs.
Users can monitor scaling progress through the endpoint UI, which tracks the transition from SCALING_CHANGE_IN_PROGRESS to SCALING_CHANGE_APPLIED. Production workloads should use service principal authentication for optimal performance, as PAT-based traffic is capped at tens of QPS. The endpoint UI now provides visibility into QPS, latency, and health metrics. High-QPS scaling is available today without opt-in, with automatic scaling for traffic spikes and support for Storage-Optimized endpoints planned for later this year.