General Concepts

The database and all its components are structured around the general concepts below, organised according to common database requirements.

The design is aligned with graph theory and is essentially inspired by Neo4j.

Graph concept

The typical elements of a graph are Node, Edge, and Property.

The image below uses the RDFS vocabulary purely as an example. This does not mean the database implements RDF concepts — RDFS is used here only to illustrate node/edge/property relationships.

A defining choice in this database: Edge and Property are both "subclasses" of Node.

In other words — everything is a node. This keeps the storage model uniform: one addressing scheme, one record discipline, and a single set of mechanisms for traversal and persistence.

Schema-less design

mGraphDB is schema-less: no type or class definition is required before storing data, and the storage engine enforces no structural constraints.

• A node may have any properties, regardless of its type.
• Two nodes with the same type may have completely different properties.
• New types, classes, and properties can be introduced at any time by simply writing new nodes — there is no migration, no schema registry, no column definition.

Types and ontologies are just data. A "class" node (see REQ-04) is a regular node in the graph; so is a property definition or an inheritance edge. An ontology is a subgraph that describes and gives meaning to the rest of the data — it is an additional viewpoint, not a gate that the engine enforces before a write is accepted.

This is the same stance as RDF/OWL and its open-world assumption: the ontology says "a foaf:Person typically has a foaf:name" — it does not prevent the existence of a person node without one. Validation, constraint checking, and inference are concerns for the application layer or a query engine built on top of the graph API, not for the storage engine.

This is a deliberate contrast with graph databases that tie schema to performance (e.g. using label-specific indexes). mGraphDB achieves performance through its storage layout (fixed-length records, direct access by ID) rather than by restricting what data can be written.

Whether and how to add an optional validation layer on top — and which schema language to adopt — is an open design question documented on the Validation and Reasoning page.

Database

The database is modular. There is currently no intention to provide multiple Persistent Layer implementations; instead, a single persistent layer covers different needs by configuration. Representative requirements:

• Space optimisation — reduce disk usage to a practical minimum:
  • in-memory index,
  • short reference (ID) types,
  • optional features (for example, a Bloom filter).
• Speed optimisation — increase throughput, especially for large data sets:
  • on-disk index files,
  • bidirectional references within the graph,
  • larger hash types.

These two directions are expressed as profiles. The first profile under development is the Small Profile (see Persistent Layer); performance-oriented profiles will follow.

Further details about the modules are on the Architecture page.