Skip to main content

Lot Genealogy at Scale: Graph Database Patterns for Traceability

Nikhil J Updated May 30, 2026 2 min read

Lot genealogy is the record of which input lots went into which output lots, through every transformation. Regulations like FDA 21 CFR Part 11 and FSMA 204 require you to trace it both ways: forward (where did lot X end up) and backward (what went into lot Y). Model that in relational tables and recall queries get slow and recursive. Model it as a graph and it becomes natural and fast, which on a recall is exactly what you need.

Why genealogy is a graph

Lots split, merge, and transform: a raw material lot is consumed across several work orders; a finished lot blends several inputs. That is a directed acyclic graph, lots are nodes, “consumed into” relationships are edges. The questions regulators ask are graph traversals:

Why relational struggles, and graph fits

In SQL, multi-level genealogy is recursive joins (or WITH RECURSIVE) that degrade as depth and volume grow; a deep recall can fan out across millions of rows. A graph database stores the relationships as first-class edges, so a traversal follows pointers instead of joining tables, and the query reads like the question:

// illustrative (Cypher-style): everything a contaminated raw lot reached
MATCH (raw:Lot {id: $lotId})-[:CONSUMED_INTO*1..]->(downstream:Lot)
RETURN downstream

The *1.. is the variable-depth traversal that is painful in SQL and idiomatic in a graph.

Patterns that keep it fast and compliant

The takeaway

Lot genealogy is a graph, so store it as one. A graph database turns multi-level forward and backward traces from slow recursive joins into fast traversals, and an append-only, audited model satisfies the tamper-evidence regulators expect. When a recall hits, the difference between a graph and a pile of recursive SQL is hours versus minutes, which is the whole point of traceability.


Implementing this at your scale?

The walkthrough above comes from production work. AvanSaber’s inventory practice has implemented variations of this pattern across multiple customer engagements.

If you are building this and want expert review of your design, or would rather have the team that built this build yours, book a discovery conversation or describe your situation at [email protected].

See our Implementation engagement model

Related reading