arcadedb

Why we included this project

Teams that keep one database for transactions, another for graph relationships, a third for search, and a fourth for embeddings will recognize the pain ArcadeDB is built around: every extra store means another deployment to babysit, another backup schedule, and glue code holding them in sync. It puts all of those shapes on a single storage layer with one ACID transaction, so a query can follow graph edges, filter document fields, and rank by cosine similarity without leaving the engine. The vector support is real, not a bolt-on. JVector-backed HNSW and Vamana/DiskANN indexes with cosine, dot product, or Euclidean distance make it usable as a production vector backend, and its origins as a conceptual fork of OrientDB mean it inherits a mature multi-model core rather than layering models onto a store built for one job. You can embed it in a JVM application or run it as a server under Docker or Kubernetes, and it accepts SQL, Cypher, Gremlin, GraphQL, MongoDB QL, and Redis, so teams can keep the query language they already know. If similarity search is today's priority but relational, graph, or time-series work will probably grow in later, this is a way to avoid betting on a single-purpose store.