Relationships and semantics
Traverse labeled relationships with Cypher, query RDF terms with SPARQL, and construct derived result graphs without changing stored data.
Review query support ↗For connected data at scale
Built for the difficult queries.
ShrikeDB tackles complex graph patterns, large datasets, and questions that cross graph, vector, RDF, key–value, and geospatial data. It keeps the same entity in view as a query moves from one kind of evidence to the next.
Cypher and SPARQL · Vector search · Geospatial and temporal queries · Typed APIs
MATCH (p:Product)-[:MADE_BY]->(b:Brand) RETURN p.name, b.name LIMIT 10
Traverse relationships and return typed rows through the Cypher API.
1,045 / 1,196ShrikeDB broad Cypher queries completed within ten seconds440 QPSOne million 768D arXiv vectors through the UVI RPC110 µsKV-backed one-minute geospatial count median
01 / The reason
Why ShrikeDB? Fair question.
A hard query can fail in three ways: it times out, its runtime becomes a guessing game, or it returns a plausible but incorrect answer. Large intermediate results, missed correlations, and careless shortcuts are common ways to get there.
We built reusable, exact query rules that work together across many difficult query shapes. They cut unnecessary work while keeping the answer intact. UVI brings the same performance focus to high-dimensional vector search.
Read the full answer
02 / The tools
Several good ways in
Use the access path suited to each request while keeping the same entity in view.
Similarity with entity data
Search durable named vector indexes, retrieve key–value payloads, and continue through graph relationships using the same entity identifier.
Try vector search in Cloud ↗Places, visits, and movement
Search by region and time, find repeated activity across dates, follow entity tracks, and connect visits through Cypher or SPARQL.
Explore a revisit query ↗03 / In practice
Start with a match. Keep asking.
Retrieve similar papers and traverse their citations in one Cypher query. The vector result carries each paper's graph identity into the match.
From a paper to its citations
Search a named embedding index, bind the returned papers, and follow their stored citation edges. The example is small enough to read and real enough to run.
See the query detailsCALL vector.knn("arxiv_embeddings", $embedding, 50, {ef: 256})
YIELD node AS paper, score
MATCH (paper:Paper)-[:CITES]->(reference:Paper)
RETURN paper, reference, score
LIMIT 2004 / Measured work
Numbers with the workload attached.
Hardware, query sets, deadlines, correctness checks, and measurement records are available with each result.
1,196 queries across 20 families
Five engines ran the full frozen set with a ten-second deadline per query.
ShrikeDB complete1,045
Neo4j complete820
Memgraph complete624
Dedicated AWS c7i.8xlarge · 3.96M nodes · 22.2M relationships. Results and correctness checks for each engine are in the benchmark table.
Open the graph results ↗Ten million observations
Search the same region across dates during a recurring UTC hour, or combine region and date range. Both engines returned matching counts.
Recurring hour + region2.237 / 30.058 ms
Region + date range0.418 / 12.389 ms
ShrikeDB / PostGIS median query latency · AWS c7i.8xlarge.
Open the geospatial results ↗One million semantic embeddings
UVI grew out of work with very high-dimensional vectors. On one million arXiv embeddings, it delivered 440.1 QPS and 19.659 ms p95 through the packed RPC. Typed Cypher reached 426.8 QPS on the same index.
UVI IDRecall@100.99968
Milvus HNSW QPS476.3
AWS c7i.8xlarge · eight clients · loaded state.
Open the vector results ↗05 / Reading
A little more context.
Engineering essays on query execution, evidence, and the data models behind useful analysis.
01 / Execution
Small answers should not require enormous searches
A worked fraud case shows why counts, candidates, and evidence need different execution.
02 / EvidenceA relationship is a claim, not a line
Build candidate episodes from observations without mistaking reporting frequency for behavior.
03 / Data contractsNo ETL still needs a contract
A valid join can double the money. Identity, grain, and source version keep direct queries honest.
06 / Get started
Pick your starting point.
Try a query in a free workspace, or start with the protocol if that is how you like to meet a database.
Create a database
Configure a server, verify readiness, load connected data, and execute a known-answer query.
Follow the walkthrough ↗Build a typed client
Browse gRPC methods, HTTP routes, messages, enums, streaming behavior, and downloadable protocol definitions.
Open the API reference ↗Deploy and observe
Configure storage, authentication, HA, backups, metrics, query tracing, and recovery checks.
Open operations guidance ↗About Us
Database engineering, down to the inconvenient details.
We build ShrikeDB for the point where a useful question becomes an unreasonable amount of work.
That point often sits between disciplines. Query semantics meet combinatorial growth. An index meets the memory hierarchy. A transaction crosses several representations of the same entity, and recovery has to put them back together. We work across those boundaries because applications live across them.
The answer has obligations.
A distinct-entity count, a count of paths, and a set of explanatory witnesses can share a pattern while requiring different information. Our query work starts with those obligations: which identities must survive, which multiplicities matter, and where a condition applies. We develop reusable exact rules with explicit applicability conditions, then check them against exhaustive small graphs and independent answers. The counterexample is a colleague. Occasionally an irritating one.
Performance includes the parts after the stopwatch.
We care about bytes moved, intermediate cardinality, allocation pressure, and the work an index can prepare once and reuse. We also care about what happens after a process stops halfway through a write. Commit visibility, durable state, and replay behavior belong in the same engineering discussion as throughput. A fast ingest path still owes the reader a coherent database.
Our vector work follows the same approach. UVI grew out of work with very high-dimensional data. We evaluate preparation, retrieval, recall, persistence, and recovery as parts of one system. A vector match becomes more useful when its identity leads directly to graph relationships, application records, and observations in place and time.
That is the work behind ShrikeDB: understanding the question, reducing the necessary work, and preserving the meaning across every boundary it crosses. Bring the awkward graph. It usually teaches us more.
A small bird. Strong opinions about storage.
The loggerhead shrike is a predatory songbird. It anchors prey on thorns or barbed wire to handle it, and stores food for later. A resourceful use of the available hardware.
We borrowed the name. The barbed wire stays outside the data center.
Meet the bird at the Cornell Lab