TechPrufer
Get started
Weaviate
Weaviate logoWeaviate · Feature trail

Query Profiling

3 posts · Apr 2026 – Jul 2026

What this trail covers

Query profiling is a per-query, opt-in debugging tool that provides detailed timing breakdowns of query execution stages across the entire cluster. This feature allows engineers to pinpoint performance bottlenecks within specific queries, replacing the previous node-per-node slow query log for real-time, granular analysis. It covers vector search, keyword scoring, and filter evaluation, and is generally available as of v1.38. The v1.37 release makes this a preview feature with per-shard timing breakdowns.

All Weaviate trails
  1. Query Profiling: See Where a Slow Query Spends Its Time | WeaviateThis post details the introduction of query profiling as a per-query, opt-in debugging tool. It contrasts this with the previous slow query log, highlighting improvements in enabling the feature (no restarts), temporary vs. persistent configuration, real-time analysis, and cross-node aggregation. It also provides a detailed breakdown of how to read the profiling output for vector search, filter evaluation, and keyword scoring, including specific metrics like `objects_took`, `filters_build_allow_list_took`, `vector_search_took`, and `knn_search_rescore_took`, and offers worked examples for common performance bottlenecks.
  2. Build a Coding Assistant with Weaviate MCP: RAG over Code & Docs | WeaviateThis post details the integration of Weaviate's built-in Model Context Protocol (MCP) server for Retrieval Augmented Generation (RAG) over code and documentation. It explains how to enable and configure the MCP server, design schemas for code and documentation chunks, implement syntactic chunking for code, and ingest data. The post highlights the benefits of hybrid search for coding assistants and demonstrates connecting LLM clients like Claude Code, Cursor, and VS Code to Weaviate via MCP.
  3. Weaviate 1.37 Release | WeaviateIntroduces query profiling as a preview feature in v1.37, enabling per-shard timing breakdowns for any search request by setting `query_profile=True` in `MetadataQuery`. The profile is structured per shard and search type, detailing metrics like `vector_search_took`, `filters_ids_matched`, `knn_search_layer_N_took`, `kwd_method`, and `total_took`. For multi-node clusters, the coordinator aggregates timings from every shard, including the node that executed it, to identify performance imbalances. Profiling uses minimal overhead, similar to slow query logging.