Skip to main content

vs HelixDB

LoraDB vs HelixDB

LoraDB is 57.2× faster overall. HelixDB is an graph-vector database (enterprise-dev image). Numbers from the same suite as the overview — identical fixtures, identical seed, identical iteration count.

52 comparable workloads25 omissions11 groups
57.2×slower
HelixDB vs LoraDB overall
Geometric-mean slowdown across the full suite.
38/ 52
Workloads won by LoraDB
14 go to a third engine.
0close calls
Within ~10% on both sides
Workloads where neither engine ran away with the row.

Same suite as the overview — only the comparison engine differs.

Overall

LoraDB sets the row; HelixDB sits at 57.2× slower.

Geometric-mean slowdown across every workload both engines run. Empty rows happen when the language can’t express the workload — they’re called out below, not hidden.

Per group

Wins by group.

For each group, the workload count, who wins it, and how the per-row tally breaks down between LoraDB, HelixDB, and any third engine that took a row.

  • setup1 workload · winner Grafeo
    LoraDB2.70× slower
    HelixDB1247× slower
    Rows · 10·0·1
  • writes7 workloads · winner Grafeo
    LoraDB0.61× slower
    HelixDB125× slower
    Rows · 73·0·4
  • scans4 workloads · winner LoraDB
    LoraDBfastest
    HelixDB287× slower
    Rows · 44·0
  • predicates12 workloads · winner LoraDB
    LoraDBfastest
    HelixDB20.9× slower
    Rows · 128·0·4
  • numerics2 workloads · winner Kuzu
    LoraDB1.08× slower
    HelixDB20.4× slower
    Rows · 20·0·2
  • aggregates4 workloads · winner LoraDB
    LoraDBfastest
    HelixDB35.5× slower
    Rows · 44·0
  • pipeline4 workloads · winner LoraDB
    LoraDBfastest
    HelixDB17.2× slower
    Rows · 42·0·2
  • lists1 workload · winner LoraDB
    LoraDBfastest
    HelixDB15.0× slower
    Rows · 10·0·1
  • sort3 workloads · winner LoraDB
    LoraDBfastest
    HelixDB16.4× slower
    Rows · 33·0
  • traversals11 workloads · winner LoraDB
    LoraDBfastest
    HelixDB133× slower
    Rows · 1111·0
  • patterns3 workloads · winner LoraDB
    LoraDBfastest
    HelixDB22.2× slower
    Rows · 33·0

Per workload

Raw timings, workload by workload.

Two columns — LoraDB and HelixDB — across every workload they share. Rows with no comparable HelixDBrun are hidden here; they’re listed in the omissions block at the bottom.

setup(1)

WinnerGrafeo
WorkloadSizeLoraDBHelixDBWinner
construct_empty—4.06 µs2.70× slower1.87 ms1247× slowerGrafeo

writes(7)

WinnerGrafeo
WorkloadSizeLoraDBHelixDBWinner
bulk_edges200606.63 µsfastest309.68 ms510× slowerLoraDB
bulk_set_match1000552.39 µs1.84× slower3.57 ms11.9× slowerKuzu
delete_node1000355.70 µs1.47× slower151.74 ms629× slowerGrafeo
set_multiple_props100021.15 µsfastest2.37 ms112× slowerLoraDB
update_set100018.01 µsfastest2.91 ms162× slowerLoraDB
write_bulk10001.46 ms1.93× slower771.22 ms1020× slowerGrafeo
write_single100014.90 µs2.20× slower153.86 ms22704× slowerGrafeo

scans(4)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
lookup_by_id1000716.64 nsfastest2.30 ms3205× slowerLoraDB
lookup_by_id_indexed1000684.00 nsfastest2.62 ms3831× slowerLoraDB
scan_filtered1000149.08 µsfastest3.82 ms25.6× slowerLoraDB
scan_label1000124.96 µsfastest2.70 ms21.6× slowerLoraDB

predicates(12)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
where_compound_and_or1000213.07 µsfastest3.23 ms15.2× slowerLoraDB
where_contains1000145.04 µsfastest3.02 ms20.8× slowerLoraDB
where_ends_with1000143.60 µsfastest2.99 ms20.8× slowerLoraDB
where_id_in_range1000142.71 µs2.02× slower3.13 ms44.3× slowerGrafeo
where_in_list1000162.42 µsfastest2.92 ms18.0× slowerLoraDB
where_modulo_eq1000127.32 µsfastest3.01 ms23.7× slowerLoraDB
where_not1000166.05 µs1.01× slower4.64 ms28.3× slowerKuzu
where_or1000147.16 µsfastest3.29 ms22.3× slowerLoraDB
where_starts_with1000146.91 µsfastest3.29 ms22.4× slowerLoraDB
where_string_gte1000180.97 µs1.07× slower4.11 ms24.4× slowerKuzu
where_subexpr1000227.59 µs1.69× slower4.73 ms35.1× slowerSurrealDB
where_two_props1000152.69 µsfastest2.56 ms16.8× slowerLoraDB

numerics(2)

WinnerKuzu
WorkloadSizeLoraDBHelixDBWinner
numeric_modulo1000144.95 µs1.02× slower2.97 ms20.8× slowerKuzu
numeric_pow1000166.22 µs1.16× slower2.87 ms20.0× slowerKuzu

aggregates(4)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
aggregate_avg100081.43 µsfastest3.20 ms39.3× slowerLoraDB
aggregate_max100079.97 µsfastest2.86 ms35.7× slowerLoraDB
aggregate_min100079.67 µsfastest2.49 ms31.3× slowerLoraDB
aggregate_sum100078.09 µsfastest2.82 ms36.1× slowerLoraDB

pipeline(4)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
case_when1000173.33 µsfastest2.78 ms16.1× slowerLoraDB
coalesce_existing1000161.92 µsfastest3.32 ms20.5× slowerLoraDB
computed_in_return1000151.15 µs1.07× slower2.99 ms21.2× slowerKuzu
with_two_chained1000313.64 µs1.41× slower4.25 ms19.1× slowerKuzu

lists(1)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
list_in_construction1000177.94 µs1.05× slower2.67 ms15.8× slowerKuzu

sort(3)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
order_by_id_asc1000167.95 µsfastest3.20 ms19.1× slowerLoraDB
order_by_multi_key1000211.99 µsfastest2.80 ms13.2× slowerLoraDB
skip_limit1000162.19 µsfastest2.87 ms17.7× slowerLoraDB

traversals(11)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
direct_record_traversal500831.70 nsfastest1.55 ms1861× slowerLoraDB
recursive_depth2500968.69 nsfastest1.69 ms1742× slowerLoraDB
recursive_depth35001.04 µsfastest1.46 ms1402× slowerLoraDB
recursive_depth55001.16 µsfastest1.65 ms1425× slowerLoraDB
relation_filter500117.78 µsfastest2.50 ms21.2× slowerLoraDB
traversal_filter_one_hop500138.99 µsfastest3.15 ms22.7× slowerLoraDB
traversal_one_hop500125.98 µsfastest2.59 ms20.5× slowerLoraDB
traversal_reverse500123.67 µsfastest2.62 ms21.2× slowerLoraDB
traversal_three_hop500236.10 µsfastest5.16 ms21.9× slowerLoraDB
traversal_two_hop500165.58 µsfastest64.61 ms390× slowerLoraDB
traversal_undirected500213.41 µsfastest4.20 ms19.7× slowerLoraDB

patterns(3)

WinnerLoraDB
WorkloadSizeLoraDBHelixDBWinner
edge_subquery_clause500213.55 µsfastest4.12 ms19.3× slowerLoraDB
star_fanout1000138.96 µsfastest2.75 ms19.8× slowerLoraDB
star_fanout_filter1000112.53 µsfastest3.24 ms28.8× slowerLoraDB

Honest omissions

Workloads HelixDB couldn’t run like-for-like.

Omissions

Workloads omitted only where the engine has no like-for-like equivalent — a missing scalar function, a different MERGE semantics, a reserved word. The reason is recorded with the workload, not silently dropped.

  • merge_existing
    HelixDB
    • HelixDB has no MERGE/upsert; emulating it needs conditional var_as_if branching.
  • merge_create
    HelixDB
    • HelixDB has no MERGE/upsert (see merge_existing).
  • distinct
    HelixDB
    • HelixDB's dedup is node-level; there is no SELECT DISTINCT <property>.
  • string_to_upper
    HelixDB
    • HelixDB's DSL has no scalar string functions (upper/lower/substring/length/concat) — only property filters and graph traversal.
  • string_to_lower
    HelixDB
    • No scalar string functions in the DSL (see string_to_upper).
  • string_substring
    HelixDB
    • No scalar string functions in the DSL (see string_to_upper).
  • string_size
    HelixDB
    • No scalar string functions in the DSL (see string_to_upper).
  • string_concat
    HelixDB
    • No scalar string functions in the DSL (see string_to_upper).
  • numeric_abs
    HelixDB
    • HelixDB's Expr supports +,-,*,/,% but no abs/floor/ceil/round.
  • numeric_floor
    HelixDB
    • HelixDB's Expr supports +,-,*,/,% but no abs/floor/ceil/round.
  • numeric_ceil
    HelixDB
    • HelixDB's Expr supports +,-,*,/,% but no abs/floor/ceil/round.
  • numeric_round
    HelixDB
    • HelixDB's Expr supports +,-,*,/,% but no abs/floor/ceil/round.
  • aggregate_count
    HelixDB
    • The HelixDB enterprise-dev image rejects `count()` dynamic queries with `rate limit exceeded` (its other 9 workloads run fine). The count handler is wired in helixdb.rs and would run on a server without that limit.
  • aggregate_collect
    HelixDB
    • aggregate_by offers Count/Sum/Min/Max/Mean, no list collect.
  • aggregate_count_distinct
    HelixDB
    • Needs count(DISTINCT); count() is rate-limited on the enterprise-dev image and value-level DISTINCT isn't exposed.
  • grouped_aggregation
    HelixDB
    • group_count groups by a stored property, not a computed value % 10 key.
  • with_pipeline
    HelixDB
    • Returns count(...); count() is rate-limited on the enterprise-dev image (see aggregate_count).
  • with_distinct_then_count
    HelixDB
    • count() rate-limited and no value-level DISTINCT.
  • with_aggregate_then_filter
    HelixDB
    • Group-then-having on a computed key (value % 10) isn't expressible; group_count keys on a stored property.
  • predicate_via_function
    HelixDB
    • WHERE size(name) needs a length() scalar the DSL doesn't provide.
  • distinct_with_order
    HelixDB
    • No value-level DISTINCT (see distinct).
  • variable_length_path
    HelixDB
    • Range-bounded variable-length expansion isn't mapped; fixed depths are benched as recursive_depth2/3/5.
  • varlen_2_to_5
    HelixDB
    • Range-bounded variable-length expansion isn't mapped (see variable_length_path).
  • varlen_exact_5
    HelixDB
    • Range-bounded variable-length expansion isn't mapped (see variable_length_path).
  • star_fanout_count
    HelixDB
    • The HelixDB enterprise-dev image rejects `count()` dynamic queries with `rate limit exceeded` (its other 9 workloads run fine); see aggregate_count.