Graph-Relational Duality
What it is
Section titled “What it is”Most stacks force a choice: store relationships in a relational database and pay the join cost forever, or copy them into a dedicated graph engine and pay the synchronization cost forever. AetheriusDB takes a third path. Every table you create can be tagged as a node table or an edge table, and the same data is then queryable through standard SQL and the ISO SQL/PGQ property-graph syntax. There is one set of tables, one transactional surface, and one query optimizer.
You don’t choose between a SQL database and a graph store — they are two lenses over the same data. An update to a row is visible to both immediately and atomically.
Why it matters
Section titled “Why it matters”The classic problem with a bolt-on graph engine is the data-silo tax: every row has to be written twice, the two stores drift apart, and any analysis that spans relational facts and graph topology turns into a cross-system join. Duality removes that tax entirely.
- No ETL between engines — graph and relational queries hit the same data, in the same transaction, with the same security rules.
- Standard SQL/PGQ syntax —
CREATE PROPERTY GRAPHandMATCHpatterns are recognised exactly as written, so existing graph knowledge transfers directly. - One source of truth — there is no second copy to keep in sync and no pipeline to maintain.
flowchart LR
classDef a fill:#1f2640,stroke:#7c5cff,color:#e8eaf0
classDef g fill:#1f2640,stroke:#4ade80,color:#4ade80
subgraph SRC[One set of tables]
U[users<br/>node table]:::a
R[retailers<br/>node table]:::a
T[purchases<br/>edge table]:::a
end
subgraph Q[Query surfaces]
SQL[Standard SQL<br/>JOIN, WHERE, GROUP BY]:::g
PGQ[SQL/PGQ<br/>MATCH path patterns]:::g
end
SRC --> SQL
SRC --> PGQ
How you use it
Section titled “How you use it”Declare your node and edge data as ordinary tables, then declare a property graph over them (ISO SQL/PGQ). Once that is in place, both relational JOINs and graph MATCH patterns work against the same data.
-- Node tables, plus an edge table (an edge is a table with two foreign keys).CREATE TABLE users ( id BIGINT PRIMARY KEY, name TEXT);
CREATE TABLE retailers ( id BIGINT PRIMARY KEY, name TEXT);
CREATE TABLE purchases ( user_id BIGINT, retailer_id BIGINT, amount DECIMAL(12, 2));
-- Declare the property graph over those tables (ISO SQL/PGQ).CREATE PROPERTY GRAPH commerce VERTEX TABLES (users KEY (id), retailers KEY (id)) EDGE TABLES ( purchases SOURCE KEY (user_id) REFERENCES users DESTINATION KEY (retailer_id) REFERENCES retailers );
-- Property-graph query: every (user -> retailer) pair linked by a purchase.SELECT a AS user_id, b AS retailer_idFROM commerce MATCH (a:users)-[:purchases]->(b:retailers);The same dataset is now reachable through JOIN for tabular reports and through
MATCH for path queries. Because both lenses share storage, an update to a
purchase is visible to both immediately and atomically.
Performance note
Section titled “Performance note”Joins along a declared foreign-key relationship have near-constant per-row cost. A foreign-key equi-join whose keys are exactly the FK columns takes a fast path built specifically for relationships. The practical effect is that joins along a declared relationship stay fast as both tables grow, and graph traversals don’t degrade into a series of random lookups at scale.
For a repeated, selective relationship join (… JOIN … WHERE <key> = <value>),
declare a Graph Index: the join is served
near-instantly, scanning neither table.
Key concepts
Section titled “Key concepts”| Concept | Meaning |
|---|---|
| Node table | A regular table whose rows represent entities a graph can traverse to. |
| Edge table | A table that connects two node tables. Each row is a directed relationship. |
| SQL/PGQ | The ISO-standard property-graph query syntax built on top of SQL. |
| Path pattern | A MATCH expression describing the shape of a traversal — nodes, edges, hops. |