NornicDB vs Neo4j — Northwind Benchmark Comparison¶

• Products seeded: 48,000, Orders seeded: 48,000
• Query workloads: 14 NornicDB / 14 Neo4j
• Iterations/query: 30 NornicDB (5 warmup) / 30 Neo4j (5 warmup)
• Seed batches / parallel sessions: 500 / 4 NornicDB; 500 / 4 Neo4j

Summary¶

Delta = (NornicDB − Neo4j) / Neo4j. Ratio compares Neo4j to NornicDB for metrics where lower is better (latency, energy, disk), and NornicDB to Neo4j for throughput (higher is better). End-to-end query-loop throughput divides measured operations by the full suite window, including warmups and per-query setup; the query-latency-only rate excludes both.

Full Query Suite¶

Each workload is reported independently with all recorded latency percentiles, range, sample count, and per-query rate.

products_per_category¶

Product counts grouped by category, with a full result sort.

Mean-latency ratio (Neo4j / NornicDB): 50.71×.

MATCH (c:Category)<-[:PART_OF]-(p:Product)
            RETURN c.categoryName AS categoryName, count(p) AS productCount
            ORDER BY productCount DESC

customer_category_distinct_orders¶

Four-hop customer-to-category traversal with distinct-order aggregation.

Mean-latency ratio (Neo4j / NornicDB): 1511.19×.

MATCH (c:Customer)-[:PURCHASED]->(o:Order)-[:ORDERS]->(p:Product)-[:PART_OF]->(cat:Category)
            RETURN c.companyName AS companyName, cat.categoryName AS categoryName, count(DISTINCT o) AS orders
            ORDER BY orders DESC, companyName ASC, categoryName ASC
            LIMIT 10

optional_match_orders_count¶

Optional product-to-order traversal with zero-match preservation and top-100 sorting.

Mean-latency ratio (Neo4j / NornicDB): 383.41×.

MATCH (p:Product)
            OPTIONAL MATCH (p)<-[r:ORDERS]-(o:Order)
            RETURN p.productName AS productName, count(o) AS orderCount
            ORDER BY orderCount DESC, productName ASC
            LIMIT 100

revenue_by_product¶

Relationship-property arithmetic and revenue aggregation grouped by product.

Mean-latency ratio (Neo4j / NornicDB): 635.27×.

MATCH (p:Product)<-[r:ORDERS]-(:Order)
            WITH p, sum(p.unitPrice * r.quantity) AS revenue
            RETURN p.productName AS productName, revenue
            ORDER BY revenue DESC, productName ASC
            LIMIT 10

products_by_supplier¶

Supplier-to-product traversal with top-N aggregation and deterministic ties.

Mean-latency ratio (Neo4j / NornicDB): 67.59×.

MATCH (s:Supplier)-[:SUPPLIES]->(p:Product)
            RETURN s.companyName AS supplier, count(p) AS products
            ORDER BY products DESC, supplier ASC
            LIMIT 25

orders_by_customer¶

Customer-to-order traversal grouped into a top-25 order-count ranking.

Mean-latency ratio (Neo4j / NornicDB): 70.39×.

MATCH (c:Customer)-[:PURCHASED]->(o:Order)
            RETURN c.companyName AS customer, count(o) AS orders
            ORDER BY orders DESC, customer ASC
            LIMIT 25

revenue_by_category¶

Three-hop category revenue aggregation from order-line quantities and product prices.

Mean-latency ratio (Neo4j / NornicDB): 450.41×.

MATCH (c:Category)<-[:PART_OF]-(p:Product)<-[r:ORDERS]-(:Order)
            RETURN c.categoryName AS category, sum(p.unitPrice * r.quantity) AS revenue
            ORDER BY revenue DESC, category ASC

revenue_by_supplier¶

Supplier-to-product-to-order traversal with revenue aggregation and top-25 sorting.

Mean-latency ratio (Neo4j / NornicDB): 551.09×.

MATCH (s:Supplier)-[:SUPPLIES]->(p:Product)<-[r:ORDERS]-(:Order)
            RETURN s.companyName AS supplier, sum(p.unitPrice * r.quantity) AS revenue
            ORDER BY revenue DESC, supplier ASC
            LIMIT 25

revenue_by_customer¶

Customer-order-product traversal with relationship-property revenue aggregation.

Mean-latency ratio (Neo4j / NornicDB): 591.45×.

MATCH (c:Customer)-[:PURCHASED]->(:Order)-[r:ORDERS]->(p:Product)
            RETURN c.companyName AS customer, sum(p.unitPrice * r.quantity) AS revenue
            ORDER BY revenue DESC, customer ASC
            LIMIT 25

order_line_sales_by_country¶

Order-line scan grouped by shipping country with line-count and unit aggregation.

Mean-latency ratio (Neo4j / NornicDB): 871.41×.

MATCH (o:Order)-[r:ORDERS]->(:Product)
            RETURN o.shipCountry AS country, count(r) AS orderLines, sum(r.quantity) AS units
            ORDER BY orderLines DESC, country ASC

low_stock_products¶

Selective numeric property filter followed by a stable top-100 product sort.

Mean-latency ratio (Neo4j / NornicDB): 66.01×.

MATCH (p:Product)
            WHERE p.unitsInStock < 25
            RETURN p.productName AS product, p.unitsInStock AS unitsInStock, p.unitPrice AS unitPrice
            ORDER BY unitsInStock ASC, product ASC
            LIMIT 100

products_in_category¶

Selective category lookup and adjacent product traversal with a top-100 result.

Mean-latency ratio (Neo4j / NornicDB): 8.34×.

MATCH (c:Category {categoryID: 7})<-[:PART_OF]-(p:Product)
            RETURN p.productName AS product, p.unitPrice AS unitPrice, p.unitsInStock AS unitsInStock
            ORDER BY product ASC
            LIMIT 100

order_line_quantity_distribution¶

Full relationship-property scan grouped by line quantity.

Mean-latency ratio (Neo4j / NornicDB): 244.98×.

MATCH ()-[r:ORDERS]->()
            RETURN r.quantity AS quantity, count(r) AS lineCount
            ORDER BY quantity ASC

customer_order_details¶

Selective customer lookup followed by order-line expansion and computed row projection.

Mean-latency ratio (Neo4j / NornicDB): 7.02×.

MATCH (c:Customer {customerID: 42})-[:PURCHASED]->(o:Order)-[r:ORDERS]->(p:Product)
            RETURN o.orderID AS orderID, p.productName AS product, r.quantity AS quantity,
                   p.unitPrice * r.quantity AS extendedPrice
            ORDER BY orderID ASC, product ASC
            LIMIT 100

Correctness¶

Seed verification. Post-seed counts reported by each database (via MATCH (n:Label) RETURN count(n) and equivalent edge queries).

Per-query result fingerprints. Each engine runs the query on the first (warmup) iteration, canonicalises the full result set, and hashes it with SHA-256. A matching row_count + matching hash means the engines returned the same data.

Intra-run stability. Every iteration of each query re-fingerprints its result set; a mismatch within a single engine's run is flagged below.

• No intra-run mismatches on either engine.

✅ All correctness checks passed — both engines seeded identically and returned identical result sets (by row count and canonical SHA-256 fingerprint) for every benchmark query.

Storage¶

Raw data files only (preallocated scratch, WAL, and indexes excluded from the headline):

• Raw data ratio: 2.81× Neo4j (larger)
• Full-dir ratio (includes scratch/WAL): 0.71× Neo4j

Power¶

Memory Pressure¶

System-wide memory during each engine's full lifecycle (startup → benchmark → shutdown).

Notes¶

• Power figures are Apple powermetrics estimates; treat as directional, not absolute. Apple's own docs note that reported averages are approximate.
• Both databases were freshly initialized before each run; Neo4j was stopped during the NornicDB run, and vice versa, to isolate measurements.
• Benchmarks ran over the Bolt protocol using the neo4j-go-driver.
• Storage classification: NornicDB raw data = *.sst + *.vlog (LSM records + value log). Neo4j raw data = neostore*store.db* (record stores). Preallocated scratch files — Badger's 8 MiB memtable (*.mem) and 1 MiB discard log (DISCARD), and Neo4j empty *.id allocation files — are excluded because their size is fixed/preallocated and does not scale with the dataset.