MySQL-flavored vector database tries to be everything at once

What it does DingoDB is a distributed database that treats relational tables and vector embeddings as “first-class citizens” in the same system. You can run scalar queries, vector similarity search, and hybrid retrieval through a MySQL-compatible SQL interface, plus SDKs and APIs. It handles sharding, replication, and index maintenance internally without external dependencies.

The interesting bit The project bets that developers would rather write SELECT ... WHERE vector_distance(...) < 0.5 than operate a separate vector database alongside Postgres or MySQL. It also claims to optimize indexes in real time without query delays and tier data between memory and disk based on access patterns.

Key highlights

• MySQL protocol compatibility: existing clients and ORMs may work out of the box
• Built-in Raft-based distributed storage (via separate Dingo-Store project)
• Automatic shard splitting/merging and cold-hot tiering for vector data
• Supports both traditional database indexes and vector indexes with “fusion” queries
• Java codebase with Docker and Ansible deployment options

Caveats

• README is heavy on adjectives (“unparalleled flexibility,” “industry-leading”) and light on specifics like supported vector index types, benchmark numbers, or SQL syntax examples
• The “unconscious background automatic index optimization” claim is vague; no detail on trade-offs or failure modes
• 1,701 stars suggests early traction, but ecosystem maturity is unclear

Verdict Worth a look if you’re already committed to SQL and want to avoid wiring a separate vector store into your stack. Skeptics should wait for concrete performance comparisons against pgvector or specialized databases like Milvus.