Scale with an external DB

When one box stops being enough, move MariaDB out.

Index Monitor does not need a dramatic replatform to grow. The usual next step is simple: keep the app, worker, and cron where they are, and point them at an external MariaDB host with more disk, more IOPS, and a better backup story.

The basic idea

Split storage from compute, not product from product.

The appliance stays the appliance. You are not rewriting services or introducing six new layers of orchestration. You are just letting a better database host do the one job it is better at: storing a growing analytics history and serving heavier export/query workloads.

before and after
small installapp + worker + cron + MariaDB on one Pi, mini-PC, or VPS
scaled installapp + worker + cron on the appliance host, MariaDB on a bigger or managed box
same inputssame Google OAuth, same routes, same worker model, same product

No architectural detour

The app still polls Google, workers still write rows, and the UI still reads the same tables. Only the database host changes.

Fastest scale-out move

If your bottleneck is storage, export churn, or database I/O, moving MariaDB usually solves it sooner than replacing the whole deployment model.

Still your infrastructure

A second box in your rack, a LAN server, or a managed MariaDB service in your own account all fit the model.

When it is worth doing

Not on day one. When the workload earns it.

Most installs should stay single-box for as long as possible. External DB becomes interesting when the appliance is clearly healthy as an app host but the database wants more room, faster storage, or better operational tooling.

Lots of retained historyKeeping more properties and longer history grows tables steadily, even when the application CPU stays mostly idle.
Heavy export useBig CSV exports and repeated read-heavy analysis runs push disk and query workload harder than normal day-to-day ingest.
Backup requirementsSnapshots, off-box backups, and restore drills are easier on a dedicated or managed database host than on a Pi with one SSD.
Multi-client agency boxA single agency appliance serving many properties often wants the app local but the database on more serious storage.

What you gain

More headroom where it matters.

More storage and IOPS

Let a proper DB host absorb larger fact tables, longer retention, and export churn without turning the application machine into a storage compromise.

Cleaner backups and restores

Dedicated or managed MariaDB hosts usually give you snapshots, scheduled backups, and operational visibility that are awkward to bolt onto hobby hardware.

Independent sizing

Keep the app and workers small if they are small. Scale the database because the database needs it, not because marketing copy said every part must get bigger together.

What to watch

A useful scale-out move, with normal tradeoffs.

Honest small print

  • Keep latency sensible. A database on the same LAN or in the same region is fine; a globe-spanning hop for every query is not.
  • Use a host you control or a managed MariaDB/MySQL service in your own account. The point is more operational headroom, not surrendering the data model.
  • Backups get easier, but the network becomes part of the dependency chain. Treat connectivity and restore testing like first-class operational work.
  • Do not split too early. A Pi or mini-PC with an SSD is enough for many installs, and extra moving parts are still moving parts.
See the hardware guide Back to the overview

Scale without drama

Keep the appliance. Give the database more room.

Start on one box. When the data volume deserves it, move MariaDB out to a stronger host and carry on with the same product and the same workflow.

Generate an install script See what the small-box path looks like