We covered SQL/PGQ in April and GRAPH_TABLE in May. This week, let’s look at the operational side: how Oracle 23ai’s property graphs differ from traditional graph database approaches, and why “operational” is the key word.
What makes a graph “operational”?
In most graph database architectures (Neo4j, Amazon Neptune, etc.), graph data is a separate store synchronized from the primary OLTP database. This means:
- Graph queries reflect a snapshot, not current state
- Data pipelines add latency between transactions and graph visibility
- Two systems to maintain, monitor, and backup
Oracle 23ai’s property graphs are defined directly on relational tables. There is no separate graph store. The graph is a logical overlay on the relational data — always current, always transactionally consistent.
-- Create a graph over live operational data
CREATE PROPERTY GRAPH fraud_detection_graph
VERTEX TABLES (
accounts KEY (account_id),
devices KEY (device_id)
)
EDGE TABLES (
transactions
SOURCE KEY (sender_id) REFERENCES accounts
DESTINATION KEY (receiver_id) REFERENCES accounts,
account_logins
SOURCE KEY (account_id) REFERENCES accounts
DESTINATION KEY (device_id) REFERENCES devices
);Querying across the live graph:
-- Detect accounts connected to a flagged account within 2 hops
SELECT *
FROM GRAPH_TABLE (
fraud_detection_graph
MATCH (flagged) -[]->{1,2} (connected)
WHERE flagged.is_fraud_flagged = TRUE
COLUMNS (connected.account_id, connected.balance)
)
WHERE connected.balance > 100000;Because the graph is defined over live tables, this query reflects every transaction that has occurred up to this moment — no batch sync delay. This is what “operational” means: real-time graph analytics on OLTP data.
