Should a Developer Keep Databases on the Compute Node or the Storage Node?
Keep active database files on low-latency storage beside compute by default, then use the storage node for backups, dumps, replicas, and archives.
That default changes when the storage node provides a deliberately engineered block-storage path, measured latency, correct durability semantics, and a recovery benefit worth the extra dependency. The decision is not simply local versus network capacity: transaction logs, data files, backups, application uploads, and disposable test databases have different write patterns and failure consequences.
Separate Database State From Dumps and Backups
Map every database-related path before choosing a node. The primary data directory and transaction log are live state; they require consistent write ordering and predictable latency. Logical dumps, base backups, archived logs, exports, and application-uploaded files have different access patterns and can often cross the network safely.
Do not mount one NAS share and place everything inside it. Keep the active database volume distinct from backup destinations and bulk application data. This makes it possible to tune, monitor, fill, snapshot, restore, and migrate each role without pretending that all persistent bytes need the same medium.
For short-lived branch databases or CI tests, rebuild time may matter more than durability. Put those on fast local scratch storage and recreate them from migrations or sanitized seeds. For a developer's daily service database, treat a local SSD failure as a recovery event and make the remote copy current enough to meet the declared recovery point.
Measure the Write Path Before Choosing a Node
Database performance depends on more than sequential throughput. Measure synchronous commit latency, random reads and writes, queue depth under backup traffic, and behavior when the network path stalls. A 10GbE link can move large files quickly while still adding latency and another failure point to every transaction.
A published PostgreSQL comparison found local NVMe delivered lower and more predictable latency than the tested network-attached cloud services, while also noting the elasticity and durability advantages of network storage. Those local and network-attached PostgreSQL benchmarks are not a home-lab guarantee, but they show why database placement needs workload measurements rather than interface speed alone.
Run a representative test with the same filesystem, sync settings, database version, dataset, and concurrency planned for the service. During the test, start a large backup or media transfer on the storage network. If tail latency or commit time becomes erratic, central capacity is not compensating for the shared path.
Place Primary Database Files Near Compute by Default
For one developer, one compute node, and modest databases, local mirrored SSDs or a recoverable local volume usually create the clearest ownership. The database process, its data files, and its write-ahead log fail together, while the storage node receives backups through a database-aware process instead of hosting an always-open filesystem remotely.
Local placement does not mean one unprotected boot drive. Separate the database volume from the OS where practical, monitor free space and drive health, reserve capacity for maintenance operations, and export backups before upgrades. Pin container or VM placement so a scheduler does not start the database on another node without its state.
Use local storage only when the recovery path is real. If replacing the compute node would require guessing at a stale copy, centralized storage may expose an existing backup failure rather than create it. Fix the backup and restore workflow before optimizing the data path.
Use the Storage Node for Backups, Replicas, and Archives
A storage node is valuable when it receives application-consistent dumps, base backups, archived transaction logs, immutable snapshots, or a database replica with its own recovery purpose. It can also hold large attachments or analytical exports while the latency-sensitive database catalog and logs remain local.
| Data role | Default location | Why | Required test |
|---|---|---|---|
| Primary data and transaction log | Compute-node SSD | Lowest and most predictable write path | Commit latency and crash recovery |
| Logical dumps | Storage node | Portable, version-aware restore source | Restore into an empty database |
| Base backup and archived logs | Storage node | Point-in-time recovery | Recover to a named timestamp |
| Read replica | Either node with its own volume | Read scaling or recovery option | Lag and promotion procedure |
| Uploads, exports, and cold analytics | Storage node | Capacity matters more than transaction latency | Concurrent transfer impact |
Community testing of PostgreSQL over NFS on a storage server produced counterintuitive results and configuration questions rather than a universal answer. That is the reason to treat remote primary storage as an engineered exception: validate sync behavior, failure handling, mount options, cache semantics, and recovery on the exact stack.
Validate Failure Recovery and the Migration Trigger
Test four events: restart the database cleanly, crash the compute node during writes, interrupt the storage link during a backup, and restore onto a blank host. Confirm the recovery point, recovery time, database integrity checks, and application reconnect behavior. A fast normal benchmark does not prove a safe interrupted write path.
The setup passes when active data has predictable latency, backups cannot overwrite or deadlock the primary, and a replacement compute node can restore without undocumented storage assumptions. Move primary files to an engineered storage service only when measured recovery or mobility benefits outweigh the network dependency; move them back local when tail latency or link outages become the dominant incident source.
For the larger architecture choice, the ZimaSpace comparison of a storage-first NAS and compute-first home server helps decide which role should remain stable as developer workloads change.
Final Setup Rule
Default to local, protected SSD storage for active database files and use the storage node for verified backups, archives, and selected replicas. Choose remote primary storage only after measuring its write semantics, tail latency, outage behavior, and recovery advantage.
Recommended products
NAS & Server Setup
More to Read
A Local RAG Setup for Research Papers, Notes, and Private Documents
Keep original documents authoritative, make indexing repeatable, require citations, and separate replaceable models from private source data.
Why Are Developers Using a Gateway Node for Private DNS, VPN, and Test Apps?
A gateway node gives private apps one controlled name and access path, while compute nodes stay unexposed and replaceable.
How to Build a Reproducible App Stack With Compose Files, Secrets, and Persistent Data Separated
Keep Compose definitions portable, secrets protected, and app data independently backed up so the stack can be rebuilt on a clean host.
