DingoDB: a multi-modal vector database behind a MySQL-compatible SQL layer

The problem DingoDB targets: vectors and relational rows in one engine

Most teams that add semantic search end up running two systems. A relational database holds the orders, users and timestamps, and a separate vector store holds the embeddings. Every query that needs both becomes an application-side join: fetch candidate IDs from the vector store, then filter them in SQL, then re-rank in code. DingoDB's stated goal is to collapse that split. The README describes it as a distributed multi-modal vector database that "integrates real-time strong consistency, relational semantics, and vector semantics into a unified platform", and it introduces Table and Vector as first-class data models. The audience is therefore a team that already has relational data and wants embeddings stored beside it, not a team building a pure nearest-neighbour service from scratch. The MySQL protocol compatibility matters here: existing drivers, ORMs and SQL habits mostly carry over, which lowers the cost of trying it. What DingoDB is not is a drop-in replacement for a dedicated vector engine tuned for one job. It is a general database that added vectors, and the feature list reads accordingly: sharding, transactions, tiered storage and indexes are all present, not just similarity search.

Architecture: Calcite parsing, a proxy tier, and a Raft-backed store

The repository layout is the clearest description of how the system is put together. The top level contains dingo-calcite, which points to Apache Calcite as the SQL parser and planner, and dingo-proxy, which is the entry point that speaks the MySQL protocol to clients. Beneath that sit dingo-exec and dingo-executor for query execution, dingo-meta-api for metadata, dingo-tso-api for timestamp oracle services (the mechanism behind the strong-consistency claim), and dingo-transaction-api for distributed transactions. Storage is split across dingo-store-api, dingo-store-local and dingo-store-proxy, and the README points to a sibling project, Dingo-Store, described as "a strongly consistent distributed storage system based on the Raft protocol". The README also states that the built-in high-availability configuration needs no external components, which is a real deployment simplification compared with systems that require you to run ZooKeeper or etcd alongside them. Two claims in the feature list deserve scrutiny rather than acceptance. First, elastic sharding with automatic splitting and merging is described, but the README gives no thresholds, no split policy and no way to observe a rebalance in progress. Second, cold-hot tiered retrieval is described as disk-based vector search that reduces memory consumption, with dynamic switching between index types; the README does not say which index types participate in that switch or what the switching trigger is. Both are plausible designs, neither is documented at the level an operator needs.

Installing DingoDB with Docker and running a first query

The README does not inline installation steps. It links out to two deployment paths in the documentation: a single-node Docker deployment and a cluster deployment driven by Ansible. The Docker path is the one to try first, and the repository ships a docker/ directory plus a dingo-dist module, which is consistent with a packaged distribution image. Because the README does not reproduce the exact image name or the compose file contents, treat the documentation page as the source of truth for those values rather than guessing at them.

Once a node is reachable, the interaction model is MySQL, and the repository provides dingo-driver and dingo-client modules for client code. The README does not print a connection command, a listening port or a CREATE TABLE example, so the port, the credentials and the column type name for a vector field all have to come from the usage and deployment documentation rather than from the README. A reasonable first exercise, once you have those values, is to create a table that carries both scalar and vector columns, insert a handful of rows with embeddings, and run one query that filters on a scalar column and orders by vector distance. Then check whether the planner used a vector index or fell back to a scan. The dingo-example module exists in the tree precisely so that you have a worked integration to read before writing your own.

Where DingoDB is the wrong tool, and what the README does not tell you

The strongest argument against DingoDB for a small project is operational weight. A Java codebase with roughly thirty Gradle modules, a separate storage project, a proxy tier, a timestamp oracle and a transaction service is a lot of moving parts for a few million vectors. If your workload is a single embedding table with no relational joins, a purpose-built vector library embedded in your process will be simpler to run and simpler to debug. The second limitation is documentation depth on the parts that hurt during an incident. The README describes automatic index optimization in the background but gives no way to observe it, pause it or confirm it finished. It describes elastic sharding without naming the configuration keys that control shard size, even though it says shard size is dynamically configurable. It does not document backup, restore or rollback at all. The third is versioning. The most recent release listed is v0.9.0 from 2024-06-14, while the default branch is develop and the last push to it was on 2026-07-10. That gap means the branch carries work that is not in any tagged release, so pinning to a release and building from develop are two different propositions. The README also does not state a supported upgrade path between releases, which is a gap to resolve before you put production data in. Finally, the README's own prose is heavy on superlatives and light on numbers: no latency figures, no recall figures, no scale figures. That is not evidence of poor engineering, but it does mean you cannot size a deployment from the README alone.

How DingoDB differs from Milvus and from pgvector

The nearest comparison in intent is Milvus, another open source vector database, and the difference is where each puts the relational layer. Milvus is built around collections and vector fields as the primary abstraction; scalar filtering exists, but the mental model starts from vectors. DingoDB starts from tables and adds vectors as a column type, with a Calcite-based SQL planner and MySQL wire compatibility on top. If your application already generates SQL and your team debugs queries by reading EXPLAIN output, DingoDB's model will feel closer to what you know. If your application is a recommendation service whose only query is top-k similarity with a filter, Milvus's model is a shorter path. The second comparison is pgvector, an extension that adds vector types to PostgreSQL. The approach there is to reuse an existing, extremely well documented relational engine and accept its scaling model. DingoDB instead builds the distributed storage, timestamp oracle and transaction layers itself, which is more work but also means horizontal scaling and strong consistency are design goals rather than add-ons. The trade-off is maturity of documentation: PostgreSQL's ecosystem has years of operational writing behind it, and DingoDB's README does not yet cover backup, upgrade or tuning at that level. A third data point is that DingoDB supports both traditional scalar index types and multiple vector index types in one system, which is the specific capability that a two-system stack has to fake with application-side joins.

Licence, build cost and what maintenance looks like

DingoDB is licensed under Apache License Version 2.0, stated in the README and present as a LICENSE file at the repository root. That is a permissive licence, so embedding it in a commercial product does not carry the source-disclosure obligations of a copyleft licence. This is a description of the licence text, not legal advice; if you are redistributing a modified build, have counsel read the NOTICE and attribution requirements. On build cost, the repository uses Gradle: build.gradle, settings.gradle, gradle.properties, a gradle/ wrapper directory and gradlew scripts are all at the top level, so a source build is a Gradle build against a JDK. The README recommends VS Code for development and mentions YourKit for profiling performance-critical work, which is a hint that JVM-level tuning is expected to matter. The module list is the real cost signal: dingo-calcite, dingo-proxy, dingo-exec, dingo-executor, dingo-meta-api, dingo-tso-api, dingo-transaction-api, dingo-store-api, dingo-store-local, dingo-store-proxy, dingo-partition-api, dingo-net-api and more. Contributing follows a documented flow: fork, branch from develop, follow Google code style, add unit tests, squash commits, and open the pull request against develop. On maintenance, the facts are these: the repository is not archived, and the last push to develop was on 2026-07-10. The README does not describe a release cadence and the listed releases stop at v0.9.0 in June 2024, so the branch and the releases tell different stories and you should check both before depending on either.

Editorial conclusion

Adopt DingoDB if your application already issues MySQL-style SQL and you want vector columns sitting next to scalar columns in the same table, without bolting a separate vector service onto the stack. Do not adopt it for a single-node prototype where the JVM build and the multi-module cluster are more machinery than you need, and do not adopt it if you require a documented release-to-release upgrade procedure, because the README does not describe one. Before committing, verify three things on your own hardware: that the Docker deployment in the docs comes up with the components you expect, that your target vector index type is supported by the version you pin, and which of the modules listed in settings.gradle you actually intend to build or consume. The last push to the develop branch was on 2026-07-10, so treat the repository as maintained but check the release tags separately from the branch.

Frequently asked questions

Official sources

1. dingodb/dingo on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases