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)

Comments URL: https://news.ycombinator.com/item?id=47952776

Points: 1

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47692363

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=47517530

Points: 5

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=47152757

Points: 2

# Comments: 0

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.

Comments URL: https://news.ycombinator.com/item?id=28384351

Points: 2

# Comments: 0

(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.

Comments URL: https://news.ycombinator.com/item?id=12525963

Points: 2

# Comments: 0