lvca

Ladybug is still very limited in terms of use cases and functionalities. Unless you just want some OLAP graph query to be faster, and that's it... You could use a fully functional DBMS with Graph OLAP functionalities, like ArcadeDB (Apache2 license):

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)

Do you know if Grafeo ever implemented the LDBC benchmark? I'd love to compare it with other Graph Databases: https://arcadedb.com/blog/neo4j-alternatives-in-2026-a-fair-...

Especially with OLAP queries.

Interesting project! The single-writer limitation is a real pain point for multi-agent systems.

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.

This resonates strongly. We've been working on exactly this problem with ArcadeDB — a multi-model database that natively supports graphs, documents, key-value, time-series, and vector search in a single engine. (https://arcadedb.com)

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.

Congrats to the SurrealDB team! Shipping 3.0 is a serious milestone.

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)

100% agree. Nobody is really interested on having ArangoDB on the cloud as a service. I guess >99% of the users are not paying and the company is running out of money (sales guys cost a lot!). I think this is a suicide for the product. Clients will remain, also because the switch is expensive. Their proprietary AQL is not easy to convert into SQL, Cypher or Gremlin....

What a story!

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.

What about https://arcadedb.com ? Open Source, Apache 2, Free for any usage. It supports SQL but also Cypher and Gremlin (and something of MongoDB and Redis query languages)

What about ArcadeDB? https://arcadedb.com (Apache2)

I agree that a pure ODBMS makes no much sense today, but OrientDB is a Multi-Model where the Object Model is one of the supported models. You can mix objects, graphs, schema-less documents and much more + using SQL as the query language. Boom!

(Disclaimer: I am the founder of OrientDB)

Great job, finally you can use GraphQL on top of OrientDB without any performance penalties.

Most of the Neo4j users don't use the TinkerPop, otherwise, it would be a drop-in replacement. If you're using Neo4j Cypher, you should use the SQL MATCH in OrientDB (very similar). Take a look at this page for the migration: https://dzone.com/articles/introducing-the-neo4j-to-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.

RTÉ Investigations Unit used OrientDB to find corruption cases: http://orientdb.com/rte-iu_case-study/

Nice reading and Kudos to the entire RethinkDB team for what they have done, especially the evangelization of the Reactive Model in the database. This inspired other vendors like OrientDB to do the same.

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.

What kind of data did you try to import into OrientDB? CSV? Or from any other GraphDB (GraphML format)?

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.

About the usage of ETL and OrientDB, what's your input file? I'd like to understand current limitation of OrientDB ETL.

Will follow a series of blog posts about all the new feature in OrientDB 2.1 and how to use them. Stay tuned.

They are both GraphDB with index-free adjacency. Look at the page http://orientdb.com/orientdb-vs-neo4j/ to know the differences between two products from the OrientDB point of view.

Hey all, we sent a Pull Request 2 days ago to the author of the Benchmark, as they used OrientDB incorrectly. Now OrientDB is the fastest in all the benchmarks, except for "singleRead" and "neighbors2", but we know why we're slower there.

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:

https://github.com/maggiolo00/nosql-tests

Hey all, we sent a Pull Request 2 days ago to the author of the Benchmark, as they used OrientDB incorrectly. Now OrientDB is the fastest in all the benchmarks, except for "singleRead" and "neighbors2", but we know why.

We are still waiting for the Arango team to update the results...

We (OrientDB Team) had the chance to look at the code and we're preparing a Pull Request. Stay tuned for the new results ;-)

@dmarcelino always open to constructive criticism: the OrientDB Community Group has thousands of users that report their feedback every day. No one was banned nor accused for that. The case with @phpnode is much different for a lot of reasons, but this is definitely not the place to discuss it ;-)

Guys, IMHO I think Charles Pick (alias phpnode) doesn't deserve such attention. Even if he's trying so hard to start a flame against OrientDB I'd rather like to celebrate the Multi-Model approach. Long life to the Multi-Model approach ;-)

Ok, so at this point you wasn't a client and you never hire a real expert?

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?

Ok, I understand who you are, but it's not fair saying the problems was on OrientDB product: we have a lot of clients running in production without such problems.

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.

Your angry comments remain anonymous. I'd like to know more about your experience and why it has been a so big failure, if this is really true.

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.

An account created 3 hours ago with just this comment? Smell like a troll.

OrientDB started disrupting the Graph Database market since the beginning by forcing existent products to improve their offer to reduce the gap with OrientDB. Some vendor already cut prices, other vendor announce to be "Multi-Model". Yes, because OrientDB is not only a Graph Database, but also a Multi-Model at the engine level.

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!

OrientDB is the most interesting alternative to MongoDB with support for Multi-Master replication and relationships: you can decide to embed or link documents:

http://www.orientechnologies.com/orientdb-vs-mongodb/

Thanks for the report, we have fixed them in ETL pages (This is due the new documentation imported from GitHub).