// the take
TiDB is a distributed SQL database that speaks the MySQL protocol while giving you horizontal scaling, HTAP via separate TiKV/TiFlash storage engines, and distributed transactions. It's aimed at teams outgrowing single-node MySQL who need scale without rearchitecting their app layer, and the recent README pivot toward 'agentic workloads' and vector search is clearly chasing the AI infra wave.
The architecture genuinely works at scale in production (PingCAP, originally built for their own needs, now runs at companies like Shopee and Square) - separating compute/storage lets you scale TiKV and TiDB nodes independently. Raft-based replication with configurable geo-placement gives real disaster recovery options, not just marketing. MySQL wire compatibility is solid enough that most apps migrate with minimal code changes, and BR (backup/restore) tooling is mature and battle-tested for petabyte-scale clusters.
This is an enormous, operationally heavy system - running it yourself means managing TiKV, PD, TiFlash, and TiDB server as separate components, which is a real commitment compared to just running MySQL or Postgres. The repo is dominated by enterprise/cloud concerns (look at the sheer volume of BR backup/restore code, KMS backends, checkpoint managers) so expect a steep learning curve before you understand what's actually load-bearing. The 'agentic workloads' and vector search framing in the README feels bolted onto a 10-year-old distributed SQL engine rather than a core design principle - worth testing vector search performance yourself before trusting the pitch. Also not all MySQL features are supported (stored procedures, triggers, foreign keys have had spotty support historically), so check compatibility docs before assuming drop-in replacement.
We read the README, the directory tree and a key source file in October 2026. Nobody pays to be listed. How we judge →