93 karma · joined June 8, 2010
Also, have you done some benchmarks, like the standard LDBC for graph databases?
This is a project we keep updated: https://github.com/ArcadeData/ldbc_graphalytics_platforms_ar...
https://arcadedb.com/blog/graph-olap-engine-the-fastest-grap....
Most importantly, ArcadeDB committed to never change its license, to avoid leaving users left in panic when KuzuDB (which Ladybug forked) was acquired by Apple and killed the very same day:
https://arcadedb.com/blog/open-source-forever-why-arcadedb-w...
(Disclaimer: I'm the founder of ArcadeDB, ask me anything)
Especially with OLAP queries.
Worth mentioning ArcadeDB (https://arcadedb.com) — it's an open-source multi-model database (Apache 2.0) that supports concurrent writes natively, with graph (OpenCypher/Gremlin), document, key-value, and time-series models in one engine. No need to fork or maintain a separate project.
It also speaks the Neo4j Bolt protocol, so existing tooling works out of the box. Could be a good fit for agent memory use cases like this.
The insight about relationships growing faster than nodes is spot on, and it's why we think the graph model is the natural fit for context layers. But in practice, you also need documents, vectors, and sometimes time-series data alongside the graph. Forcing everything into a single model (or stitching together multiple databases) creates friction that kills agent workflows.
On the GQL/Cypher vs SQL point — agreed on token efficiency. We support both SQL (extended with graph capabilities) and Cypher-style syntax, and the difference in prompt size for traversal queries is dramatic. An N-hop relationship query that takes 5+ lines of SQL JOINs is a single readable line in a graph query language. For LLM-generated queries, that's not just an aesthetic win — it directly reduces error rates and token costs.
Re: GraphRAG — we've seen the same convergence. Vector similarity to find the right neighborhood, then graph traversal for structured context. Having both in one engine (ArcadeDB supports vector indexing natively) means you avoid the API orchestration overhead you mention. One query, one database, full context.
The training gap for graph query languages is real but closing fast. As more agent frameworks adopt graph-based context, the flywheel will kick in.
This is also a broader validation moment for the multi-model database space. In a market historically dominated by specialized, single-purpose systems (a separate DB for graphs, another for documents, another for search), it's meaningful that multiple independent projects — SurrealDB, ArcadeDB, and others — are converging on the same thesis: one database, many models. That kind of convergence signals the idea has real legs, not just as an engineering curiosity but as something the market is starting to demand.
If you're evaluating options in this space, worth also looking at ArcadeDB (https://arcadedb.com, Apache 2.0). It covers the same models — graph, document, key/value, time-series, full-text search, vector embeddings — but differs in a few practical ways:
- Query language: ArcadeDB speaks SQL, Cypher (OpenCypher-compliant with TCK testing), Gremlin, GraphQL, and MongoDB QL out of the box, so existing tooling tends to work without migration. The 26.2.1 release also added the Neo4j Bolt wire protocol, so standard Neo4j drivers connect directly.
- TimeSeries model is coming next week already compatible with the time series landscape, highly optimized
- License: Apache 2.0 with an explicit commitment to never change it. SurrealDB 3.0 ships under BSL 1.1, which converts to Apache 2.0 in 2030
- Runtime: Java 21, embeddable as a library or client-server, runs on Linux/macOS/Windows (x86_64 and ARM64).
Not saying one is better for all use cases — both are interesting takes on the multi-model problem. If BSL or SurrealQL lock-in are considerations for your team, ArcadeDB is in the same conversation.
Disclosure: I'm the founder of ArcadeDB and of OrientDB (now part of SAP - one of the DBMS SurrealDB was inspired by)
It's hard to make OSS sustainable without millions of $ and VCs trying to turn that OSS tech in a huge business. With OrientDB we got lucky, not it's the past... Now I'm experimenting with a different approach of redistributing GitHub Sponsorships to the developers that actively work to the project:
https://blog.arcadedb.com/welcome-to-arcadedb#whats-next
After almost 18 months it's still far from being sustainable. Pure OSS is one of the hardest field to make some money because of the average developer: they just take without giving anything back in terms of work (contributing) or money.
(Disclaimer: I am the founder of OrientDB)
For IBM Graph (that is Titan under the hood) you should install the TinkerPop plugin in Neo4j, export it as GraphML and then import it into IBM Graph. The query must be completely rewritten. In Gremlin 3 there is a minimal pattern matching, maybe you could try using that.
Running a company where a large part of the users is developers is very hard. The secret sauce is providing a good product and create a business where some of the users would pay to have something more, like support and/or an Enterprise edition.
The truth is, AFAIK, no NoSQL company backed by VC is still profitable today. Not even MongoDB that has got more than $300M and is able to collect just $60M/year by spending much more to be up & running.
Disclaimer: I'm the author of OrientDB.
Have you already tried http://orientdb.com/docs/last/Graph-Batch-Insert.html?
In case you import data from a RDBMS, you can use Teleporter: http://orientdb.com/docs/last/Teleporter-Home.html.
We are still waiting for the Arango team to update the results...
However, who is interested in running the tests themselves, just clone this repository:
We are still waiting for the Arango team to update the results...
1) I don't know where did you find this expert. Plugin/driver authors couldn't be certified. Was this expert certified? And why didn't you ask for a certified guy to the Orient Technologies company?
2) Did you ever purchased any professional support from Orient Technologies company?
You used experimental parts like ETL (was still in development) and you guys were aware of this. Furthermore your roadmap was completely unreal, specially managing a new technology that nobody in your company was skilled on. If I was the CTO of your company I'd hire somebody skilled on OrientDB if this would become the foundation of my infrastructure. And you guys didn't model a Graph, but just kept the old model trying hard to let it working with OrientDB.
Last but not least, you never paid the renewal and in order to help you we provided support for FREE for 2 months. Sorry, but the main problem there wasn't the product, but the person that worked on this migration.
Maybe you lost your job because you wasn't able to do this migration, but please don't put mud on OrientDB.
Also generic comments like "backup strategy is not existent" when OrientDB supports backup/restore and export/import let me think you want just trolling this topic. Seriously, if you had a real bad experience on using OrientDB, please let us know by motivating all the statements above. Just drop an email to info at the company web site. Thanks.
Today OrientDB releases the Enterprise Edition FREE for development. For production users are free to going with Enterprise (commercial) or Community (always FREE - Apache2 licensed).
It's a big momentum for the whole DBMS market!