What makes TuringDB so fast?

Traditional graph databases (Neo4j, Memgraph) store each node as a self-contained record with all its properties and references to edges, efficient for single lookups but wasteful for analytical scans. TuringDB stores data column-oriented: each property in its own contiguous array, proven in engines like ClickHouse and DuckDB.

• Label scans touch only the label column, not full node records.
• Property filters scan a single column instead of deserializing nodes.
• Aggregations operate on dense integer arrays.

Neo4j and Memgraph use the Volcano (iterator) model, processing one row at a time, with per-row overhead and no vectorization. TuringDB uses a streaming columnar execution engine: each operator processes a whole batch (a column) at once.

• SIMD vectorization: many values per CPU instruction.
• Reduced overhead: one function call per batch, not per row.
• Better branch prediction on homogeneous data.

TuringDB's immutable DataPart architecture means read queries never contend with writes. Even for a single query with no concurrent load, the zero-locking design skips the entire lock-management code path, so there's no lock-acquisition overhead at all.

Neo4j and Memgraph rely on indexes to accelerate property lookups, and here they use the indexes from the dataset dump. TuringDB uses no explicit index structures: its columnar layout makes property scans inherently fast, the column itself acting as a natural index. Even with the competitors' indexes available, TuringDB still wins most property-filter queries.