TiDB, an open source distributed SQL database that speaks the MySQL wire protocol and serves transactional and analytical queries from one engine.
TiDB is an open source distributed SQL database built by PingCAP. It separates compute from storage: a stateless SQL layer parses and plans queries, a distributed transactional key value store called TiKV holds the rows, and a placement driver keeps the cluster's metadata and decides where data lives. Because the SQL layer speaks the MySQL wire protocol, existing MySQL clients, drivers and tools connect to it unchanged and familiar SQL works as written.
The design is aimed at workloads that outgrow a single MySQL server. Storage is spread across Raft replicated regions that the cluster rebalances on its own, so capacity grows by adding storage nodes rather than by sharding in the application. TiDB also serves analytical queries against the same data that receives writes, which lets one system answer both operational lookups and aggregate reporting without a separate warehouse or a pipeline to copy rows between them.
This image runs all three components on a single machine, which is the smallest arrangement that is still a genuine TiDB cluster rather than a mock storage stub. It is a faithful place to develop against, evaluate and learn the real component topology, and a starting point for scaling out later.
TiDB creates its root account with no password at all, so the single most important thing an image can do is make sure that default never reaches a customer. The cloudimg image ships with no bootstrapped cluster whatsoever, and generates a per VM root credential on first boot, supplying it as part of the very first cluster bootstrap so an empty password never exists as a completed state. The cluster's internal components and the TiDB Dashboard are bound to loopback, leaving only the SQL port reachable, and the dashboard is reached over an SSH tunnel.
Storage sits on a dedicated data volume rather than the operating system disk, and the memory ceilings for each component are computed at start up from the machine's own RAM, so one image behaves correctly across machine sizes instead of three components each claiming most of the same memory. Every build is verified end to end on a freshly launched machine: the credential is proven to work, an empty password is proven to be refused, and real rows are written and read back after a restart. Paired with a written deploy guide and 24/7 cloudimg support.
Real screenshots taken while testing this image against its deployment guide.