Problem
Currently, our project relies on Neo4j for data storage. While this works for basic CRUD operations, we face significant performance bottlenecks when handling complex, deeply connected data (e.g., multi-hop queries, knowledge graphs, or real-time recommendation engines). Traditional SQL JOINs are inefficient, and existing NoSQL solutions lack native graph traversal capabilities.
Proposed solution
I propose implementing a unified graph database abstraction layer that supports Neo4j as the primary backend, while ensuring compatibility with high-performance alternatives such as FalkorDB and NornicDB.
Key objectives:
-
Unified Adapter Layer: Develop a common interface to abstract the underlying Cypher/GQL dialects. This allows developers to switch between Neo4j, FalkorDB, and NornicDB with minimal configuration changes.
-
Performance Optimization: Leverage FalkorDB's low-latency, memory-efficient architecture for real-time caching scenarios, while utilizing Neo4j's robustness for large-scale persistence.
-
Documentation & Tooling: Provide clear setup guides for each supported database, including Docker Compose templates for local development.
Alternatives considered
-
Vendor-Specific Implementation: Building exclusively for Neo4j creates a hard dependency and prevents us from leveraging specialized features (like FalkorDB’s Redis-based speed).
-
Manual Query Management: Writing separate query sets for each database type is unsustainable and increases maintenance burden.
3.Sticking with Current Stack: Forcing relational databases to handle graph logic results in exponential query latency as data complexity grows.
Supporting Neo4j, FalkorDB, and NornicDB concurrently through an abstraction layer ensures the system remains performant, flexible, and future-proof.
Related database type
None
Problem
Currently, our project relies on Neo4j for data storage. While this works for basic CRUD operations, we face significant performance bottlenecks when handling complex, deeply connected data (e.g., multi-hop queries, knowledge graphs, or real-time recommendation engines). Traditional SQL JOINs are inefficient, and existing NoSQL solutions lack native graph traversal capabilities.
Proposed solution
I propose implementing a unified graph database abstraction layer that supports Neo4j as the primary backend, while ensuring compatibility with high-performance alternatives such as FalkorDB and NornicDB.
Key objectives:
Unified Adapter Layer: Develop a common interface to abstract the underlying Cypher/GQL dialects. This allows developers to switch between Neo4j, FalkorDB, and NornicDB with minimal configuration changes.
Performance Optimization: Leverage FalkorDB's low-latency, memory-efficient architecture for real-time caching scenarios, while utilizing Neo4j's robustness for large-scale persistence.
Documentation & Tooling: Provide clear setup guides for each supported database, including Docker Compose templates for local development.
Alternatives considered
Vendor-Specific Implementation: Building exclusively for Neo4j creates a hard dependency and prevents us from leveraging specialized features (like FalkorDB’s Redis-based speed).
Manual Query Management: Writing separate query sets for each database type is unsustainable and increases maintenance burden.
3.Sticking with Current Stack: Forcing relational databases to handle graph logic results in exponential query latency as data complexity grows.
Supporting Neo4j, FalkorDB, and NornicDB concurrently through an abstraction layer ensures the system remains performant, flexible, and future-proof.
Related database type
None