Graph databases have evolved from niche technologies into essential components of modern data platforms. While Neo4j remains the most recognisable name in the graph world – built from the ground up for relationships and traversal – relational giants such as PostgreSQL and Oracle have steadily integrated native graph capabilities into their ecosystems.
Oracle, in particular, has a long history in this area: its Spatial and Graph option dates back to Oracle 8i (released in 1999) and has since developed into a mature, enterprise-grade framework supporting both property graphs and semantic RDF models. Meanwhile, PostgreSQL has introduced the pg_graph and AGE extensions, enabling developers to work with graph data directly within SQL, bridging traditional relational models with modern graph analytics.
In this article, we move from concepts (covered in the first part) to practice:
- how to store and query graph data in Neo4j, PostgreSQL, and Oracle,
- what each platform does best,
- and how to choose the right tool for your specific use case.
Whether you are building recommendation systems, analysing networks, or mapping data lineage, each of these platforms offers a unique perspective on how to think and query in graphs.
- 1. Neo4j: The Native Graph Pioneer
- 2. PostgreSQL + pg_graph: A Practical Example
- 3. Oracle Spatial and Graph: Enterprise Graph Analytics
- 4. Comparing Neo4j, PostgreSQL, and Oracle
- Conclusion
1. Neo4j: The Native Graph Pioneer
When people discuss graph databases, Neo4j is usually the first name mentioned – and for good reason. It is one of the earliest and most mature graph-native databases, designed specifically for modelling and querying relationships without the constraints of tables and joins.
1.1 Data Model
Neo4j uses a property graph model, in which everything is represented as follows:
- Nodes → entities such as people, companies, or transactions
- Relationships (edges) → connections between nodes, always directed
- Properties → key-value pairs attached to both nodes and relationships
This model enables flexible, schema-optional structures. You can start small, add new relationship types over time, and evolve your data model as your understanding develops – something much harder to achieve with rigid relational schemas.
1.2 Cypher Query Language
Neo4j introduced Cypher, now the most widely adopted graph query language and the inspiration for the upcoming GQL standard (Graph Query Language).
Example:
MATCH (a:Person)-[:KNOWS]->(b:Person)
WHERE a.name = 'Alice'
RETURN b.name;This simple pattern-matching syntax expresses in one line what would require multiple joins in SQL. Cypher enables you to navigate complex networks, calculate shortest paths, and perform deep traversals intuitively.
1.3 Performance and Architecture
Neo4j uses a native graph storage engine – each node directly references its connected nodes, eliminating the need for expensive joins or index lookups. This design enables extremely fast traversals, even across millions of relationships.
It supports:
- ACID transactions
- Clustered deployments for high availability
- Bolt protocol for efficient client-server communication
- Neo4j Aura – a fully managed cloud service for easy scaling
1.4 Practical Usage
Common Neo4j use cases include:
- Recommendation systems (“users who bought this also bought…”)
- Fraud detection (identifying indirect relationships between accounts)
- Knowledge graphs for AI and search systems
- Network and IT topology analysis
As Neo4j is graph-first, developers can begin exploring data relationships almost immediately, without needing to design a relational schema first.
1.5 Integration and Ecosystem
Neo4j integrates well with:
- Python (via the neo4j driver and py2neo)
- Graph Data Science (GDS) library – prebuilt graph algorithms such as PageRank, community detection, and similarity
- APOC procedures – an extensive library of utilities for importing, transforming, and analysing graph data
- ETL tools such as Informatica, Airbyte, and Kafka Connect for ingesting relational data into Neo4j
It is also possible to combine Neo4j with PostgreSQL or Oracle in hybrid setups, for example, by keeping master data in relational databases and using Neo4j for graph exploration and analytics.
1.6 Strengths and Limitations
| Strengths | Limitations |
| Native graph storage and traversal | Requires separate infrastructure |
| Intuitive Cypher language | Limited SQL interoperability |
| Mature ecosystem (GDS, APOC, drivers) | Commercial licensing required for enterprise features |
| Excellent visualisation tools | Data migration from RDBMS may require transformation |
1.7 Summary
Neo4j remains the benchmark for graph-native performance and developer experience. Its flexibility, traversal speed, and intuitive Cypher syntax make it ideal for use cases where relationships are central to the problem, not merely metadata.
However, as graph features mature in systems such as PostgreSQL and Oracle, organisations now have more choice: whether to adopt Neo4j fully or extend existing databases with graph capabilities.
2. PostgreSQL + pg_graph: A Practical Example
As graph concepts become part of mainstream SQL, PostgreSQL has emerged as one of the first open-source databases to support them natively. With version 18, PostgreSQL continues to expand its graph capabilities through the pg_graph extension, an implementation of the emerging SQL/PGQ (Property Graph Queries) standard. This allows developers to define vertices and edges directly within SQL, without leaving the relational model.
2.1 Installation
CREATE EXTENSION pg_graph;This enables graph functionality in your PostgreSQL database.
2.2 Creating a Simple Graph
Let’s model a simple social network – who knows whom:
CREATE PROPERTY GRAPH social_graph
VERTEX person LABEL person PROPERTIES (name TEXT)
EDGE knows PROPERTIES (since DATE);The person vertex represents people, while knows defines the relationships between them.
2.3 Inserting Data
INSERT INTO social_graph.person VALUES ('Alice'), ('Bob'), ('Charlie');
INSERT INTO social_graph.knows VALUES
((SELECT id FROM social_graph.person WHERE name='Alice'),
(SELECT id FROM social_graph.person WHERE name='Bob'), '2020-05-01'),
((SELECT id FROM social_graph.person WHERE name='Bob'),
(SELECT id FROM social_graph.person WHERE name='Charlie'), '2021-07-10');This creates a small network where Alice knows Bob, and Bob knows Charlie.
2.4 Querying the Graph
SELECT *
FROM GRAPH_TABLE(
MATCH (a:person)-[:knows]->(b:person)
WHERE a.name = 'Alice'
RETURN b.name
);This query returns all people whom Alice knows – no joins required. It uses the same concept as Cypher’s pattern-matching syntax in Neo4j, but is expressed natively in SQL.
2.5 Why It Matters
The pg_graph extension provides PostgreSQL users with a way to explore relationships and paths directly in SQL, while retaining all the familiar strengths of the relational model – ACID compliance, indexing, security, and ecosystem compatibility.
It is ideal for:
- Lightweight graph exploration
- Adding relationship awareness to existing data models
- Integrating graph insights into analytical queries or dashboards
However, because it is built on top of relational storage, pg_graph is not optimised for deep graph traversals or high-volume network analytics like native graph engines (e.g. Neo4j or Oracle PGX).
Instead, it acts as a bridge, bringing graph capabilities into the world of relational data without requiring changes to infrastructure or query language.
2.6 Summary
PostgreSQL’s pg_graph marks a major step in unifying SQL and graph thinking. It will not replace specialised graph engines, but it enables developers to model and query relationships directly within the database they use every day.
3. Oracle Spatial and Graph: Enterprise Graph Analytics
While PostgreSQL is only beginning to adopt graph features, Oracle has supported them for over two decades. The Oracle Spatial and Graph option was first introduced in Oracle Database 8i (1999) and has since evolved into one of the most mature and powerful frameworks for managing connected data at scale.
It provides two complementary models:
- Property Graph – for general-purpose graph structures (nodes, edges, and attributes)
- RDF Graph (Semantic Graph) – for representing semantic relationships using RDF triples and SPARQL queries
Together, these make Oracle not only a database but a comprehensive analytics platform for both operational and semantic graph workloads.
3.1 Property Graph Basics
The property graph model in Oracle allows you to define vertices, edges, and their attributes as either relational tables or in-memory data structures. Each vertex and edge has a unique ID, label, and key-value properties.
Example definition (conceptual syntax):
CREATE PROPERTY GRAPH social_graph
VERTEX person LABELS (person) PROPERTIES (name STRING)
EDGE knows SOURCE KEY (person.id) DESTINATION KEY (person.id)
PROPERTIES (since DATE);Data can be queried using PGQL (Property Graph Query Language), a declarative graph language developed by Oracle and now part of the ISO SQL/PGQ standardisation effort.
3.2 Querying Graph Data
PGQL queries will look familiar if you have used Cypher or SQL/PGQ before:
SELECT friend.name
FROM MATCH (p:person)-[k:knows]->(friend:person)
WHERE p.name = 'Alice';This query returns all of Alice’s friends by traversing the knows relationships, eliminating the need for manual joins or complex recursive SQL. PGQL also supports pattern matching, filtering, and path analysis, and can be embedded in standard SQL statements for hybrid workloads.
3.3 Oracle PGX: In-Memory Graph Analytics
For large-scale graph processing, Oracle provides the PGX (Parallel Graph Analytics) engine. It loads graph data from the database into memory and runs advanced algorithms in parallel, making it ideal for massive graphs with millions of nodes and edges.
PGX includes built-in algorithms for:
- PageRank
- Community detection
- Shortest paths
- Centrality and influence scoring
It can be accessed directly from SQL, Java, or REST APIs, and also powers Oracle Graph Studio in Oracle Cloud.
3.4 Integration and Use Cases
Oracle’s graph features are fully integrated into the wider Oracle ecosystem:
- Informatica, ODI, and Oracle Data Integrator can transfer data between relational and graph tables.
- Oracle Analytics Cloud can visualise graph results.
- REST APIs from PGX enable easy consumption of graph insights in applications or microservices.
Typical use cases include:
- Fraud detection and AML – uncovering hidden transaction networks
- Data lineage and metadata management – mapping dependencies across systems
- Telecom and logistics networks – modelling and optimising connections
- Recommendation engines – combining graph analysis with machine learning
3.5 Strengths and Limitations
| Strengths | Limitations |
| Mature enterprise implementation | Requires Oracle Enterprise licensing |
| Native SQL + PGQL integration | More complex to set up and tune |
| Scalable, parallel analytics with PGX | Less flexible for experimental graph schemas |
| Deep integration with the Oracle ecosystem | Primarily designed for enterprise workloads |
3.6 Summary
Oracle Spatial and Graph has led enterprise graph analytics for over 25 years. Its combination of relational reliability, graph-native algorithms, and enterprise integration makes it ideal for large organisations requiring scalable, production-grade graph insights.
Although it is heavier than PostgreSQL and less developer-friendly than Neo4j, it remains the gold standard for complex, high-volume graph analytics in integrated enterprise environments.
4. Comparing Neo4j, PostgreSQL, and Oracle
As graph capabilities become more widely available across database platforms, it is important to understand where each system stands and which one best suits a particular type of workload.
4.1 Data Model and Storage
| Feature | Neo4j | PostgreSQL | Oracle |
| Core Model | Native property graph | Relational with graph extension (pg_graph / AGE) | Property graph + RDF (Semantic Graph) |
| Storage | Native graph engine | Relational tables with graph abstraction | Relational tables or in-memory PGX engine |
| Schema | Schema-optional | Fully schema-based | Schema-based with flexible graph definition |
Neo4j stores graphs natively, while PostgreSQL and Oracle map them onto relational structures with Oracle offering both relational and in–memory graph models.
4.2 Query Languages
| Neo4j | PostgreSQL | Oracle | |
| Graph Query Language | Cypher | SQL/PGQ | PGQL (precursor to SQL/PGQ) |
| SQL Integration | No native SQL, but JDBC/ODBC supported | Native SQL syntax with graph constructs | Full SQL and PGQL interoperability |
| Learning Curve | Easy to read and intuitive | Familiar for SQL users | Moderate (mix of SQL and PGQL concepts) |
Neo4j’s Cypher remains the most expressive for traversals, but SQL/PGQ and PGQL are closing the gap, bringing graph capabilities to existing SQL users.
4.3 Performance and Scalability
| Neo4j | PostgreSQL | Oracle | |
| Traversal Speed | Excellent (native adjacency) | Good for moderate graphs | Excellent with PGX (parallel in-memory) |
| Analytics | Built-in Graph Data Science library | Limited but improving | Advanced graph algorithms in PGX |
| Horizontal Scaling | Supported via clustering | Standard PostgreSQL scaling | Enterprise-grade clustering and parallelism |
Neo4j excels at traversal-heavy queries, Oracle leads in large-scale analytics, and PostgreSQL offers a balance for lightweight or hybrid scenarios.
4.4 Ecosystem and Integration
| Neo4j | PostgreSQL | Oracle | |
| Tooling | Bloom, GDS, APOC, Aura Cloud | pg_graph, AGE, standard SQL tools | Spatial & Graph Studio, PGX, OCI Graph Cloud |
| Integration | Kafka, Python, Java, ETL tools | Broad SQL ecosystem | Tight integration with Oracle stack |
| Deployment | Self-managed or cloud (Aura) | On-premises, cloud, open-source | On-prem isesor OCI managed service |
4.5 Typical Use Cases
| Use Case | Neo4j | PostgreSQL | Oracle |
| Recommendation systems | ✅ Excellent | ✅ Good | ✅ Good |
| Fraud detection | ✅ Excellent | ⚪ Moderate | ✅ Excellent |
| Data lineage / governance | ⚪ Moderate | ✅ Good | ✅ Excellent |
| Social / network analysis | ✅ Excellent | ⚪ Limited | ✅ Good |
| Hybrid SQL + Graph workloads | ⚪ Limited | ✅ Excellent | ✅ Excellent |
4.6 When to Choose Which
- Choose Neo4j
- if your project is fundamentally about relationships – such as recommendation engines, fraud networks, or knowledge graphs – and you require native graph performance and flexibility.
- Choose PostgreSQL
- if you wish to extend an existing SQL-based environment with graph features, experiment quickly, or integrate graphs into broader analytics workflows.
- Choose Oracle
- if you operate in a large enterprise setting and need scalable, production-grade graph analytics tightly integrated with transactional and spatial data.
4.7 Summary
Neo4j remains the pure graph-first solution, PostgreSQL offers the most accessible hybrid approach, and Oracle stands out for enterprise-scale integration and analytics capabilities.
Together, they illustrate that graph thinking is no longer a niche capability – it is becoming a core part of modern data strategy, regardless of platform.
Conclusion
The ability to query relationships natively – without abandoning SQL – marks an important step in the evolution of relational databases.
PostgreSQL provides a lightweight, open-source way to experiment with graph analytics, while Oracle delivers enterprise-grade performance and advanced algorithms through its PGX engine. Neo4j, meanwhile, remains the gold standard for native graph modelling and traversal.
All three platforms support executing graph queries directly on the database server, avoiding the common and costly antipattern of fetching large subgraphs into backend or frontend applications just to compute operations such as traverse() or shortest_path() manually. Keeping graph logic close to the data reduces latency, minimises data movement, and enables your architecture to scale more effectively.
Together, these technologies show that graph thinking can now reside within your existing data infrastructure – without the need for separate engines or disconnected tools. For data teams, this means faster insights, cleaner integration, and a unified approach to both relational and connected data.
