Database consolidation — six instances down to one

Context

The Pi4 node hosts most of the workshop's data services: health sensors, calendar, projects, knowledge base, music intel, dashboards. Over time, six separate MariaDB instances had been spun up — one per side-project, each started as an isolated container. The result: 91% RAM steadily in use, growing swap, and no headroom left to add anything new.

Constraint

The workshop's golden rule: no visible downtime for downstream services. Several apps are always writing (health, ntfy, dashboards); a hard restart would have been spotted within seconds by external probes.

An additional constraint learned the hard way: on a saturated Pi4, a docker restart can take sshd down with it. So no mass restart — one instance at a time.

Decision

Rather than tune six engines, keep only one — mln-mariadb — and bring the six databases home into it, each with its own user and its own narrow grants. Gradual migration, database by database, following the same drill:

1. mysqldump to a file on external disk
2. Create the database and user on mln-mariadb
3. Restore via mysql < dump.sql
4. Switch the connection string in the consuming app (env var)
5. Watch for 24 hours before dropping the old instance

Measurement

Before: 6 MariaDB instances, 91% RAM, swap permanently active. After: 1 instance, 47% RAM, swap idle, query latency unchanged. External probes saw nothing.

What remains

On the learning side: a proven migration drill, reusable for similar consolidations (Postgres, Redis). On the ops side: a single engine to back up, patch, monitor. On the capacity side: enough headroom to absorb the next two services (knowledge api + meilisearch) without buying new hardware.

← All case studies