Understanding Native Multi-Model Databases: Concepts, Use Cases, and AQL Examples

The article, based on an ArangoDB white‑paper translation and the author's own insights, introduces native multi‑model databases, which integrate document, key‑value, and graph storage within a single engine and expose a unified declarative query language.

It discusses the difficulty of selecting a single database for complex projects, the theory of "one size does not fit all," and how native multi‑model databases address the need for multiple data models without the operational overhead of managing separate systems.

Native multi‑model databases store each document with a unique primary key in a KV store, represent graph vertices and edges as JSON documents, and thus allow queries that span across models in a single statement.

The article presents a practical example: managing an aircraft maintenance team where millions of hierarchical components (aircraft, engines, parts) require different storage models. JSON documents store component attributes, while a graph captures the hierarchical relationships between vertices.

Several AQL (ArangoDB Query Language) examples illustrate typical queries:

FOR part IN parts FILTER part.nextMaintenance <= "2016-12-15" RETURN part

FOR component IN 0..4 INBOUND "parts/Screw56744" GRAPH "FleetGraph" FILTER component.isMaintainable == true LIMIT 1 RETURN component

FOR c IN components FILTER c.nextMaintenance <= "2016-12-15" RETURN {id: c._id, nextMaintenance: c.nextMaintenance}

A more complex multi‑model query combines document filtering, graph traversal, and a join with a contacts collection to return the part, its responsible component, and contact information:

FOR p IN parts FILTER p.nextMaintenance <= "2016-12-15" FOR c IN 0..4 INBOUND p GRAPH "FleetGraph" FILTER c.isMaintainable == true LIMIT 1 FOR person IN contacts FILTER person._key == c.contact RETURN {part: p._id, component: c, contact: person}

The article also shares modeling best‑practices: JSON’s flexibility for both structured and unstructured data, graphs for natural relationship modeling, and the performance benefits of mixing models in a single engine.

Finally, it lists numerous scenarios where multi‑model databases excel, such as content management, e‑commerce, organizational hierarchies, fraud detection, IoT, knowledge graphs, logistics, infrastructure management, recommendation engines, social networks, traffic systems, version control, and workflow management, concluding that multi‑model databases represent a key emerging trend and introducing the author’s own ChuBaoDB project.