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.

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

The useful answer starts with the operating model. Who depends on this service, what breaks when it is unavailable, and how quickly does it need to be restored? Those questions matter more than the product name.

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 rest of this guide turns that context into a baseline design, implementation order, validation checks, and buying notes. That is the TechGeeks bias: a setup is not good because it worked once. It is good when it can be explained, tested, and recovered.

Recommended Baseline

Use three buckets in the design: production data, fast local recovery, and offsite recovery. Production data may live on a NAS, mini PC, DAS, cloud drive, or application server. Fast local recovery can be snapshots, image backups, app exports, or a second local copy. Offsite recovery must survive the house, the account, or the device being unavailable.

Do not let sync pretend to be backup. Sync keeps locations aligned; backup keeps recoverable history. If deletion, encryption, or corruption can propagate to every copy within minutes, the setup still needs a separate recovery layer.

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

Before copying the recommendation, fill out this worksheet for your own home or lab. The right answer can change when the same tool is used for family photos, router access, media playback, cameras, or a disposable test stack.

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

Consider the smallest version of the design that would answer the question for one device, one user, or one service. Build that pilot, write down the result, and expand only when the validation checklist passes. That keeps the reader out of the common trap of turning a single practical problem into an expensive rebuild.

Walk the decision in priority order. Put irreplaceable data first: family photos, personal documents, password-vault exports, app databases, and project files. Put painful-but-replaceable data next: VM images, media metadata, downloads that took time to curate, and configuration folders. Put disposable cache last. Then give each tier a working location, a fast restore path, and a separate recovery path.

This is where many storage articles get too shallow. A NAS, DAS, cloud drive, or sync tool is only one part of the answer. The reader needs to know what happens after the laptop is lost, after the NAS pool fails, after an account is locked, and after a sync client deletes the wrong tree. The example succeeds only when a restore from a separate path works without trusting the original system.

Rollout And Recovery Plan

Roll this out in three passes. First, identify the data that is truly hard to replace: photos, documents, app databases, password-vault exports, encryption keys, and machine backups. Second, build the working path that people will use every day. Third, prove recovery from a separate path before deleting, migrating, or reorganizing the original copy.

The recovery test should be specific enough to catch real gaps. Restore one normal folder, one recently changed file, and one application-owned data set such as a photo-library database, container volume, or backup catalog. Check filenames, timestamps, permissions, thumbnails, and whether the restored data opens on a different machine. A backup that only restores onto the same healthy system is not the recovery plan you want during a hardware failure.

Implementation Details

Implement this in a maintenance window, even if the word maintenance feels too formal for a home lab. The point is to avoid changing several hidden dependencies while someone else expects the internet, photos, media, smart home, or passwords to keep working.

1. Create a database inventory with app, engine, version, credentials location, and backup method.
2. Use one database user per app even on a shared server.
3. Schedule database-aware dumps and offsite retention.
4. Monitor disk space, connections, slow queries, and failed backups.
5. 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.

Evidence To Collect

The article should leave the reader with something they can verify. Collecting evidence sounds formal, but it can be as small as a restored folder, a router config export, a playback dashboard capture, or a clean-browser login test.

• 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

The best design is the one that still makes sense three months later. Put these checks on a calendar so the setup does not depend on memory.

• 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.

Storage maintenance should always include a restore test. Green check marks from backup jobs are useful, but they do not prove that permissions, databases, metadata, encryption keys, and offsite access will work when the original system is gone.

When To Spend Money

Product links make sense only after the reader knows what problem the purchase solves. Use this table to keep buying advice tied to evidence, not anxiety or a tempting sale price.

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

• Media Server Storage Design: NAS, CIFS/NFS Mounts, Permissions, and Local Cache
• Backup and Disaster Recovery for Plex, Sonarr, Radarr, Tdarr, Prowlarr, and SABnzbd
• Monitoring and Health Checks for a Plex and Arr Homelab

What This Does Not Protect or Validate

This guide does not guarantee that vendor pricing, product bundles, firmware behavior, subscription terms, or cloud policies will stay the same. Verify current documentation before final buying or migration decisions.

It also does not replace a full security, backup, or disaster-recovery program. The goal is to give you a practical design, the tests that prove it, and the boundaries that keep the recommendation honest.

RAID, snapshots, sync, and cloud drives are useful controls, but none of them proves recovery until you restore real data from a separate path.

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

• https://www.postgresql.org/docs/current/backup.html
• https://mariadb.com/kb/en/backup-and-restore-overview/
• https://docs.docker.com/compose/
• https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/

Final Thought

The right answer is the one you can operate, document, test, and recover without guessing.