One Shared Database Server or One Database Per App?
Tech GuruFor most small homelabs, a shared database server is easier to back up, monitor, and secure once you understand it. Per-app database containers are simpler at first and reduce coupling, but they can turn backup, patching, and resource use into a mess if every stack hides its own database.
Design principle: Separate working data, local recovery, and offsite recovery. One box can help, but one box should not be the whole plan.
The Short Version
- For most small homelabs, a shared database server is easier to back up, monitor, and secure once you understand it. Per-app database containers are simpler at first and reduce coupling, but they can turn backup, patching, and resource use into a mess if every stack hides its own database.
- Use the decision matrix below, then prove the result with the validation checklist before making it the default.
Why This Matters Now
Start with the applications and the operator. Record each required engine and version, extension, database size, write pattern, maintenance tolerance, recovery point, and recovery time. A shared service is attractive only when one administrator can operate those combined requirements without hiding an unacceptable outage dependency.
Many self-hosted apps quietly add PostgreSQL, MariaDB, Redis, or SQLite state that must be backed up.
The right choice depends on skill level, blast radius, backup maturity, and how often apps are changed.
A shared server needs good permissions; per-app databases need good inventory.
The baseline below uses separate databases and roles on a shared engine where requirements align, while keeping incompatible or unusually critical applications isolated. It sequences inventory, one low-risk migration, application-aware backup, isolated restore, observation, and connection-string rollback.
Recommended Baseline
Separate live database state from recovery artifacts. The engine needs reliable production storage; operators need recent logical dumps or engine-supported backups for granular recovery; and a protected off-host copy must remain available if the database host, its credentials, or its storage is lost.
Replication and volume synchronization can copy corruption, deletion, or a bad migration as faithfully as valid transactions. Retain engine-aware recovery points outside the shared server and test them against a compatible disposable instance before calling the topology recoverable.
Decision Matrix
| Choice | Best Fit | Watch Point |
|---|---|---|
| Per-app database container | Beginner stacks and isolation. | Many backup jobs and hidden state. |
| Shared PostgreSQL/MariaDB VM | Central backup, monitoring, and patching. | One outage can affect many apps. |
| Managed external database | Small business or critical workloads. | Cost and dependency. |
| SQLite per app | Lightweight apps and simple backup. | Concurrency and app support limits. |
Decision Worksheet
Complete one worksheet row per application before consolidating anything. Include engine, supported major version, extensions, collation, database and role names, current volume, credential location, backup command, restore order, maintenance window, owner, and the old connection string needed for rollback.
| Worksheet Item | What To Write Down | Why It Matters |
|---|---|---|
| Primary question | Should I run one shared database server or one database per app? | This keeps the article tied to the reader's real decision instead of drifting into a generic product comparison. |
| Affected systems | People, apps, and devices that create or need the files, photos, backups, databases, or shares. | Readers should know who and what they are protecting before they choose hardware, software, or a cloud service. |
| Failure model | Deletion, ransomware, drive failure, bad sync, account lockout, theft, fire, and hardware replacement. | Different failures need different controls. This row prevents RAID, sync, VPN, or MFA from being treated as magic. |
| Proof test | Restore a real folder, one recently changed file, and one app-owned data set to a clean location. | A recommendation is not proven until it survives a small, repeatable test using realistic data, clients, or accounts. |
| Rollback path | Keep the original copy and credentials available until restores, permissions, and metadata are confirmed. | A reversible change is less stressful, easier to explain, and less likely to turn a weekend project into an outage. |
| Measurement to capture | Power, storage, network, and backup impact before the design becomes production. | Numbers, logs, screenshots, or restore notes give the reader confidence that the decision was based on evidence. |
Shared Database Does Not Mean Shared Blast Radius
A shared database server can simplify memory use, backups, monitoring, and updates, but each app still needs separate users, separate databases or schemas, least privilege, and a restore plan. One admin password reused across apps turns convenience into a shared compromise.
Track connection limits, migration timing, backup windows, and app-specific restore tests. If one app upgrade requires a database restart that breaks five other services, the shared server is now part of your change-management process.
Real-World Example
Pilot with one low-risk application that officially supports the target engine version. Restore its backup to a new database, use a distinct least-privilege role, point a disposable application instance at it, exercise representative reads and writes, and observe logs before moving the production connection.
Rank applications by database risk rather than container count. An identity provider, password service, or home-automation history may deserve isolation and a tighter recovery objective; a replaceable dashboard may tolerate shared maintenance. Cache and queue stores still need an explicit persistence decision even when their contents can be rebuilt.
A topology diagram alone misses the hard part: engine upgrades, extension compatibility, credential rotation, and recovery order. Follow a failed shared host through restoring the engine, roles, databases, and application secrets. Then verify one application at a time so a healthy TCP port is not mistaken for recovered service state.
Rollout And Recovery Plan
Roll out consolidation in three passes. Inventory and back up every existing application database first. Build the shared engine with separate roles, monitoring, and a tested restore target second. Move one low-risk application last, retain its old volume unchanged, and expand only after both service validation and rollback succeed.
A useful database recovery drill starts from a clean compatible engine, recreates required roles and extensions, restores the chosen backup, and launches a disposable application instance with copied configuration. Verify expected records, a representative write, ownership, sequences, time zones, and application migrations. Restoring files onto the production engine alone does not exercise the full dependency chain.
Implementation Details
Use a declared maintenance window for database version changes, storage moves, credential rotation, and application cutover. Stop or quiesce writes when the documented backup method requires it, capture a final recovery point, and avoid combining engine upgrade, schema migration, and network redesign in the same change.
- Create a database inventory with app, engine, version, credentials location, and backup method.
- Use one database user per app even on a shared server.
- Schedule database-aware dumps and offsite retention.
- Monitor disk space, connections, slow queries, and failed backups.
- Document restore order for apps that depend on shared services.
Record these details while you build, not after the memory has already gone fuzzy:
- Power, storage, network, and backup impact before the design becomes production.
- The simplest test that proves the setup can survive a normal failure.
- The alert that tells you the system stopped working.
- The rollback path if the change breaks the household.
Validation and Evidence to Collect
Database evidence includes the exact engine and version, backup command and timestamp, restore log, required extensions, role grants, application migration output, representative read and write, and elapsed recovery time. Keep secrets and personal rows out of screenshots and editorial artifacts.
- A data inventory that separates irreplaceable, painful-to-recreate, and disposable data.
- Screenshots or logs from the latest backup job, snapshot job, scrub, SMART check, and offsite sync.
- A restore note showing what was restored, where it was restored, how long it took, and what did not come back cleanly.
- A credential note proving backup administration is separate from normal daily user access.
- Capacity math that includes snapshots, retention, app databases, photo growth, and replacement-drive budget.
Failure Signals
- Backups complete but nobody has restored from them.
- Snapshots and sync jobs live on the same system as the only important copy.
- Drive, UPS, or scrub alerts go to an inbox nobody checks.
- Cloud-only files, app databases, or metadata are missing from the backup plan.
Adopt, Pilot, Defer, Avoid
- Adopt: Adopt the design when it separates working data, local recovery, and offsite or offline recovery.
- Pilot: Pilot with one folder, one app export, or one photo subset before reorganizing the whole data set.
- Defer: Wait when the current setup is stable, backed up, monitored, and the proposed change is mostly curiosity.
- Avoid: Avoid treating RAID, snapshots, sync, or cloud drive alone as a complete backup plan.
Validation Checklist
- Each app has its own database user and least-privilege permissions.
- Backups include schemas, data, and required extensions.
- A restored app can connect to a restored database.
- Database server patching has a rollback plan.
- Credentials are not stored in plain Git.
Common Mistakes
- Giving every app the same database superuser password.
- Assuming container recreation restores database data.
- Running multiple hidden databases with no backup inventory.
- Putting the shared database on unreliable storage.
- Ignoring Redis or other stateful sidecars.
Troubleshooting
| Symptom | Likely Cause | First Check |
|---|---|---|
| Restore fails | Backup captured files but missed app state, permissions, keys, or database exports. | Restore to a clean folder or VM and compare timestamps, permissions, and app behavior. |
| Storage feels slow | Network, disks, protocol overhead, Wi-Fi, or client limits are the real bottleneck. | Test wired transfer speed, disk health, and client link speed separately. |
| Backups look successful but feel risky | Jobs report completion without proving recovery. | Schedule a restore drill and record exactly what did and did not come back. |
Maintenance Cadence
A shared engine reduces the number of services only if its inventory stays current. Calendar patch review, failed-backup alerts, storage and connection checks, role review, application compatibility review, and a rotating isolated restore so undocumented databases do not accumulate behind one endpoint.
- Monthly: Check alerts, backups, free space, updates, and the services that other people depend on.
- Quarterly: Run a small failure drill and confirm the recovery note still works.
- Yearly: Review whether the design is still worth its power, maintenance, and support cost.
Pair database backup status with application-level restoration. A successful dump may omit roles, extensions, large objects, or companion state, while a clean volume snapshot may capture an unsafe point in time. Start the restored application and exercise its critical path before accepting the backup.
When To Spend Money
Hardware spending is justified only after database evidence identifies memory pressure, storage latency, capacity, power-loss exposure, or recovery-time limits. More RAM or faster NVMe cannot correct incompatible engines, shared superuser credentials, or a backup that has never restored.
| Stage | Signal | Practical Buying Guidance |
|---|---|---|
| Do not buy yet | Restore has not been tested, data has not been tiered, or the existing bottleneck is unknown. | Spend time on inventory, restore proof, labels, and documentation before buying another enclosure. |
| Small useful spend | Backups are working but the weak point is power, replacement media, or offsite transport. | UPS with shutdown signaling, external backup drive, spare drive, drive labels, or a safe storage case. |
| Larger upgrade | Capacity, restore time, drive bays, network throughput, or app-data reliability is now a measured constraint. | NAS, larger disks, 2.5GbE/10GbE path, offsite target, or a separate compute host. |
Useful Gear And Buyer Notes
The product links below are intentionally search links, starting with mini PC 32GB RAM, because model numbers, bundles, and prices change quickly. Use them to compare categories, then verify exact specifications against the article's decision points before buying. For infrastructure gear, prioritize firmware support, replaceability, warranty, idle power, and recovery behavior over headline specs.
Affiliate disclosure: As an Amazon Associate, TechGeeks may earn from qualifying purchases. The product links below are buying references, not a requirement to buy a specific brand or seller. Verify compatibility, seller quality, warranty, and current specs before ordering.
- Amazon search: mini PC 32GB RAM
- Amazon search: NVMe SSD 2TB
- Amazon search: NAS backup drive
- Amazon search: UPS USB
Related TechGeeks resources
- How Do You Back Up Docker Volumes and Databases Properly?
- Homelab Backup Strategy: NAS, Offsite Copies, and Restore Tests
- RAID, ZFS Snapshots, Sync, and Backup: What Each One Does Not Protect
Security, Privacy, Legal, Recovery, and Evidence Limits
Security and privacy boundaries: Give every application a separate database and role, restrict network listeners, encrypt remote connections where the threat model requires it, and keep secrets out of images and source control. Dumps, replicas, query logs, and monitoring can contain personal or application-sensitive records, so protect them with the same care as the live database.
Legal and recovery boundaries: Database consolidation does not change retention, deletion, licensing, or data-residency obligations. Before moving an app, capture its supported database engine and version, take an application-consistent logical backup, preserve the old volume, and record the connection-string rollback needed to return the application to its previous database.
What the evidence does not prove: A successful TCP connection does not prove schema compatibility, extension availability, transaction integrity, or acceptable latency. A completed dump does not prove restoreability; a replica is not an independent backup; and restoring one application does not prove every tenant on a shared server can meet its recovery-time and recovery-point objectives.
Practical FAQ
Should I run one shared database server or one database per app?
For most small homelabs, a shared database server is easier to back up, monitor, and secure once you understand it. Per-app database containers are simpler at first and reduce coupling, but they can turn backup, patching, and resource use into a mess if every stack hides its own database. The important next step is to validate the recommendation with one small test before treating it as the default.
References
- PostgreSQL: Backup and Restore
- MariaDB: Backup and Restore
- Docker: Back up, restore, or migrate data volumes
- Redis persistence
- NIST SP 1800-11B: Data Integrity
Final Thought
The right answer is the one you can operate, document, test, and recover without guessing.
Need help applying this?
Bring TechGeeks into the real environment.
If you are working through this on a live network, WordPress site, Linux server, AI workflow, or PisoWiFi deployment, send the context and we can help turn it into a practical plan.
