Skip to main content

ADR 017: Evaluation Graph vs. Relational Database

Date: Nov 2025

Status: Accepted

Decision Makers: @jonasfrz , @luckey

Context​

This ADR evaluates two database approaches — Graph Databases (GraphDBs) and Relational Database Management Systems (RDBMS) — to determine their suitability for storing and querying metadata according to the DCAT-AP.DE specification. The comparison focuses on the practical implications of each technology in terms of data model extensibility, linked-data query capabilities (e.g., JSON-LD APIs), system stability, maintainability within the existing development team, and performance for complex DCAT queries.

The goal is to identify which database paradigm provides the best balance between flexibility, scalability, and operational reliability for a sustainable metadata infrastructure.

Applicable checked Architecture Principles​

  • [full] Technological consistency to ensure maintainability - RDBMS is widely used in our technology
  • [full] Security by design - Better for RDBMS

Criteria​

  • Mult 1: Extensibility of data model at runtime
  • Mult 4: Queryability in a linked-data fashion (DCAT-AP.DE API with JSON-LD)
  • Mult 5: Stability
    • How mature and stable is the toolkit
  • Mult 5: Maintainability
    • How easy is the development with the resources available in the team
    • Are tooling and libraries widely available
  • Mult 3: Performance
    • How fast is the retrieval of an average complex DCAT query

Evaluation

  • Mult: 1-5
  • Scale: 1:Low, 2:Medium, 3:High, 4:Very High

Alternatives​

  • Graph DB
    • Complex dynamic dependencies can be retrieved/managed natively by design
    • Optimal for structures that change very often
    • Assumption: For many deeply nested structures, the performance is assumed to be better than in relation databases, especially, if no optimization (in rel db) has been done
  • Relational DB
    • Better when data model is rather static
    • Easier in development, since POJOs are static/known/typed
    • Can be combined easily with CIVITAS/CORE authentication model
    • Chosen tech stack (spring, quarkus) natively work with relational databases
    • Core data model is static

Negative Consequences​

... for Graph DB

  • Combination of different paradigms will be burdensome
  • Knowledge in team is rather poor
  • Tooling is less mature
  • More tooling is required in additional layers (additional dependencies)
  • Authorization is more difficult

... for Relational DB

  • More effort required for serialization and deserialization from LD-API to relational database
  • Extension of schema is rather static

Positive Benefits​

... of GraphDBs

  • Deep, recursive traversals: Ideal for pathfinding — e.g., social graphs, fraud detection, or network topologies.
  • Flexible schema evolution: When introducing new node types or relationships, you don’t need to restructure tables.
  • Real-time graph analytics: Excellent for shortest path calculations, community detection, and recommendation systems.

... of RDBMS

  • Static data with a clear schema: Perfect for well-defined, stable data models.
  • ACID transactions and maturity: RDBMSs have been refined over decades, while graph databases are still catching up in this area.
  • Massive aggregations across many rows (SUM, COUNT, AVG): Columnar systems like PostgreSQL with TimescaleDB or DuckDB are extremely efficient here.

Comparison with Criteria​

CriteriumGraphDBEvalRDBMSEval
Extensibility of data model at runtimeVery high — new node or relationship types can be added without schema migrations. Ideal for evolving or semi-structured data.4Medium — schema changes (ALTER TABLE, migrations) are often complex and can impact existing data and queries. Runtime-Extension of data model must be impemented with generic "Properties"-Table or the like.2
Queryability in a linked-data fashion (e.g., DCAT-AP.DE API with JSON-LD)Very high — designed for linked data; native support for RDF, SPARQL, and JSON-LD makes cross-entity traversal natural.16Medium — achievable through joins, but less intuitive for deeply nested linked data. Can be achieved with some effort with libraries (e.g. OnTop, Dynamic Entity Graph for Spring Boot).8
Stability (maturity and toolkit robustness)Medium — modern GraphDBs like Neo4j or GraphDB (Ontotext) are stable but not as battle-tested as RDBMS for high-transaction workloads.10Very high — decades of optimization and strong ACID guarantees; proven in production at global scale.20
Maintainability (ease of development & tooling availability)Medium — good developer tooling in Neo4j, but fewer mature libraries and ORM-like abstractions; requires graph thinking.10High — wide ecosystem, extensive community, mature tooling, and developer familiarity.15
Performance (retrieval of complex DCAT queries)High for graph-shaped queries — traversing linked entities is extremely fast due to index-free adjacency.9High for tabular aggregations — but complex recursive joins can degrade performance quickly.9
4954

Decision​

We decide for RDBMS for storing meta data in the CIVITAS/CORE. Reasons include:

  • Meta data model will be rather static (benefits of GraphDB cannot be leveraged)
  • Queriability of meta data is not assumed to be as complex to require GraphDB features (e.g. used in analytics of social graphs) - meta data are ususally not correlated in a complex fashion, and if so, meta data can be transferred temporarily for analytics
  • RDBMS are battle-tested and stable of decades
  • Authoriation model can be combined with meta data easily since authorization (and all other configuration data) will be stored in a RDBMS