Three databases, on purpose

The platform runs three relational databases — PostgreSQL (10.100.100.13), MariaDB (10.100.100.14), and MySQL (10.100.100.15) — each on its own VM, each on local disk, not on the cluster's NFS.

Why three? Because real applications disagree about what they want. Some expect Postgres; some expect the MySQL world — and "the MySQL world" is itself two products now. MariaDB began life as a fork of MySQL, but the two have drifted far enough apart that they're no longer drop-in identical: different defaults, different licensing, and even different names for the same tuning knob (more on that next page). Running all three means whatever you decide to self-host has a home, and it makes for a more honest teaching setup — you see the two dominant lineages of open-source relational databases, and both sides of the MySQL/MariaDB split, set up the same disciplined way.

Why on their own VMs with local disk, rather than as pods on NFS? Databases are the one workload where storage semantics really matter — fsync behaviour, latency, locking. NFS is great for shared app files and genuinely risky for a database's data files. A dedicated VM with local (ZFS-backed) block storage gives the database the predictable, low-latency disk it wants, and a clean failure domain of its own.

PostgreSQL-Server (.13)   4 vCPU / 4 GiB / 250 GiB local disk
MariaDB-Server    (.14)   4 vCPU / 4 GiB / 250 GiB local disk
MySQL-Server      (.15)   4 vCPU / 4 GiB / 250 GiB local disk

Why we use this: "use the right tool" applies within a category too. NFS for app volumes, local disk for databases. Putting a database on network storage because "it's the storage we have" is a classic way to earn mysterious corruption and stalls.

Diagram