Improve query performance
Begin with a correct query and representative data. Measure the request through the interface your application uses, including result transfer. A count query and a query returning every matched row perform different amounts of work.
Establish a baseline
Save the query, selected database, input parameters, result count, concurrency, and elapsed time. Measure the first request separately from repeated requests because startup, data loading, and caches can affect latency.
Use EXPLAIN to inspect a supported plan without executing it. Use PROFILE for a read query when you want execution timing:
PROFILE MATCH (p:Person) RETURN count(*) AS peoplePROFILE executes its child query. Its row_count is the number of output rows, so this aggregate normally reports one row even when it examines many people. See Results And Inspection for the returned fields.
Reduce unnecessary work
| Pattern | Adjustment |
|---|---|
Large result payloads |
Return only needed properties and apply an appropriate result limit. |
Broad graph expansion |
Use known labels, relationship types, endpoint filters, and finite path bounds. |
Vector results removed by graph filters |
Request enough vector candidates to leave useful results after filtering; measure the extra search cost. |
Repeated payload lookups |
Hydrate final candidates with KV after narrowing the row set where query semantics permit. |
SpaceKey full-index search |
Add the entity, time interval, or geographic shape required by the question. |
Parquet scans |
Check mapping eligibility, selected columns, source freshness, and row groups read. |
Changing a filter or limit can change results. Compare values and multiplicities after each rewrite. LIMIT bounds returned rows; it does not guarantee that every preceding aggregate or sort can stop early.
Understand execution choices
ShrikeDB can use ordinary graph execution, specialized exact count/path operations, graph analytics, vector retrieval, or lakehouse views. A specialized path is selected only for a query shape it supports; other shapes use an available general path or return a diagnostic.
For bounded Cypher paths, relationship uniqueness and multiplicity affect counts. Replacing a trail query with a walk count changes its meaning. Keep those semantics intact when tuning a query.
Inspect traces
Use query and vector traces to separate planning, execution, and result-delivery costs. Look for intermediate row growth, cache behavior, selected data source, and fallback reasons. For lakehouse queries, inspect bytes read and row groups touched. For SpaceKey, return candidates, seeks, planning_us, and execution_us as shown in Geospatial and spatiotemporal indexing.
The experimental learned optimizer defaults to off. Its shadow mode records sampled recommendations while the existing dispatcher continues executing requests. Enabling shadow observation does not apply the suggested alternative.