One Shared Database Server or One Database Per App?
Tech GuruQuick Answer
Use per-app databases when applications need different engine versions, independent maintenance, or separate failure boundaries. A shared engine can simplify backup and monitoring when those requirements align and you can accept its shared downtime. In either model, inventory every stateful service, give each app its own limited credentials, and test restoration. Consolidating containers is not a reason to combine incompatible applications or reuse a database superuser account.
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.
| Record per app | Required detail | Decision affected |
|---|---|---|
| Compatibility | Engine and supported major version, extensions, collation, and migration requirements. | Which apps can share an engine at all. |
| Access | Database/schema, least-privilege role, secret retrieval, and network listeners. | Which data the app can reach. |
| Availability | Maintenance window, tolerated outage, recovery point, and recovery time. | Whether shared downtime is acceptable. |
| Capacity | Database growth, connections, storage latency, and observed resource demand. | Whether one app can exhaust shared capacity. |
| Recovery | Backup method, roles/extensions, companion files, restore order, and acceptance test. | Whether the app can recover on a clean compatible engine. |
| Cutover | Old volume and configuration, write-stop point, acceptance criteria, and rollback decision. | How to avoid silently losing writes accepted after the move. |
Separate Permissions, Shared Availability
Separate app databases and least-privilege roles limit what each application can access; they do not isolate an engine restart, host failure, or shared resource shortage. Consolidate only when those shared interruptions are acceptable. Never give every app the same database administrator credential, and retain a restoration plan for each application.
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.
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: TechGeeks did not perform a database migration, isolation audit, or restore drill for this guide. 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.
