Deploy MariaDB + Autocache Reaper
MariaDB 11.8 that bills less memory by dropping page cache it isn't using
MariaDB
Just deployed
/var/lib/mysql
Deploy and Host MariaDB + Autocache Reaper with Railway
MariaDB that bills less memory. This is the official mariadb:11.8 image with autocache-reaper wrapping the server. The reaper watches which cached file data the database re-reads and drops the rest.
About Hosting MariaDB + Autocache Reaper
Railway bills a service's memory as the kernel counts it, and that count includes the page cache. For MariaDB, by default MariaDB reads through the page cache as well as its buffer pool, so the same data can be held twice. That cache stays billed after the workload stops touching it.
The reaper drops it at a pace bounded by the disk's measured IO headroom, and backs off when what it dropped comes back. The database starts first and keeps running whatever the reaper does, and signals are passed through, so a redeploy is a clean shutdown. Only file cache is touched, never the database's own memory: dropped cache is re-read from the volume if needed, and dirty pages are never dropped.
In a 5-minute run with a dump and point queries, memory ended at 206 MB instead of 702 MB, with 292 MB evicted and nothing re-read. That was measured in a test container, not on Railway. Your saving depends on your workload: data that is re-read all the time stays cached.
That is one short run. On a mostly idle Postgres deployment over 19 hours, the same reaper kept re-reading small files it had just dropped, about 10 KB/s. It is harmless to a quiet database, but it is wasted work, and a fix is in progress. MariaDB may behave the same way until then.
Common Use Cases
- Databases whose memory bill stays high after dumps or bulk imports
- Databases larger than their working set
- Small and side-project databases where page cache is a large share of the bill
Dependencies for MariaDB + Autocache Reaper Hosting
- A Railway volume mounted at
/var/lib/mysql(included in this template)
Deployment Dependencies
- Image:
ghcr.io/housek/acr-mariadb:11.8, rebuilt automatically whenever its base image changes, after tests and a start/stop check pass
Implementation Details
MariaDB 11.8 LTS, started with --innodb-buffer-pool-size=1G. The buffer pool is MariaDB's own memory, which the reaper never touches, so lower that flag if you want a smaller bill on a small database.
Variables: MARIADB_URL (private network), MARIADB_PUBLIC_URL (TCP proxy), MARIADBHOST, MARIADBPORT, MARIADBUSER, MARIADBPASSWORD, MARIADBDATABASE, MARIADB_DATABASE, MARIADB_ROOT_PASSWORD. A TCP proxy on port 3306 is included.
Optional switches:
AUTOCACHE_DRY_RUN=1: log what would be evicted, evict nothing.AUTOCACHE_OFF=1: kill switch, plain MariaDB behaviour.- Without a restart, from a shell in the service:
echo live > /dev/shm/autocache-mode(ordry-run,pause).
The reaper logs one JSON line per event on stderr: start, roots, and a periodic summary with usage, file, evicted_total and reread_total.
Why Deploy MariaDB + Autocache Reaper on Railway?
Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.
By deploying MariaDB + Autocache Reaper on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.
Template Content
