Research Summary
I’m currently researching this to gather insights from other AI engineers and assess its feasibility for our use case. Our goal is to evaluate what would be required for conversion and scaling to determine whether it’s a viable direction. I’ll share the findings once the initial evaluation is complete.
Key Concerns for Your Use Case
ACID Transactions: Not yet confirmed — this is critical for maintaining chatbot data integrity.
Real-Time Updates: The immutable architecture may present challenges for systems requiring frequent updates.
Write Performance: Unclear — the system appears optimized for read-heavy workloads rather than write operations.
Concurrent Writes: Potential issues due to immutable DataParts structure.
Why Neo4j Remains the Stronger Choice
-
Proven ACID compliance, ensuring transactional integrity.
-
Optimized for real-time updates and concurrent access.
-
Mature and well-supported ecosystem with robust tooling.
-
Record-oriented storage better suited for frequent data updates.
-
Demonstrated performance reliability for this specific use case.
Additional Context
Further research is needed to confirm whether ACID transactions are fully supported. Other aspects, such as write performance and concurrency, would require direct testing to produce reliable benchmarks.
In my earlier research on ontology-driven graph databases, these considerations were key factors in selecting Neo4j. I’ve also completed extensive training in Neo4j, particularly in the Graph Data Science (GDS) library, which includes a rich set of built-in algorithms and analytical tools. Versions 4 through 5 of my systems utilized GDS effectively, but I’ve since developed faster computational methods that have significantly reduced processing time.
That said, data retrieval has never been my main bottleneck it’s typically processing speed (tokens per second). Even with the OpenAI API, throughput remains constrained since I build my own reasoning layers rather than relying on opaque, closed LLM reasoning models. This allows me to fully track and understand how my system derives its conclusions through the custom-built reasoning and GAP memory layers.
I prefer developing these foundational components myself whenever practical. While it’s not always the fastest approach especially in competitive environments it provides a deep sense of fulfillment. For me, the challenge isn’t about outperforming others; it’s about testing whether I can build something as capable (or better) than what exists today. It’s a self-driven pursuit of mastery part science, part art, and wholly rewarding.
The downside to all this though is madness in that you could end up infinite coding to always find a better way hence all the versions here over time are that concept of build test love, than blow it up and rebuild better with all that understanding. 
