Blob Stores, Storage Layout, Database Choices, Capacity Planning, and Data Separation: Configuration, Design Choices, and Tradeoffs

1. Start with failure domains, not folder names

A storage layout should make an operational promise explicit. Separate stores may isolate growth, retention, access policy, cost class, or recovery scope. A single store may reduce administrative overhead and make capacity easier to reason about. Neither is inherently “enterprise.” The design is good when the reason for each boundary is observable and supportable.

2. Shared versus purpose-specific blob stores

More stores are not automatically safer. Sonatype’s planning guidance notes that excessive blob-store count can make cleanup/search and disk-capacity reasoning harder, especially when several file stores share one physical filesystem.

3. File storage versus S3-style object storage

The deciding question is not “cloud or not?” It is where Nexus runs, the latency budget, required durability, provider support, and the team’s ability to operate the storage backend. Cross-region or cross-cloud blob access can convert every package request into a network performance problem.

4. H2 versus PostgreSQL: convenience is not a production criterion

H2 keeps the disposable lab simple and is the current default for new installations. Current Sonatype requirements cap supported H2 workload and exclude H2 container deployments. PostgreSQL is recommended for production and separates database lifecycle, backup, capacity, monitoring, and availability from the Nexus process.

5. Capacity headroom is a policy decision

Suppose a team retains 120 GiB of current blobs, adds 18 GiB/month, removes about 8 GiB/month through supported retention/cleanup, and wants twelve months before a capacity expansion. Net annual growth is:

\[(18-8)\times 12=120\text{ GiB}\]

Projected retained bytes become 240 GiB before overhead. If the organization requires storage to remain below 70% utilization to leave room for temporary work, cleanup lag, unexpected releases, and recovery operations, the capacity target is approximately:

\[240 / 0.70 \approx 343\text{ GiB}\]

Then add local data-directory/database/log/temporary requirements separately. The 4 GB read-only threshold is an emergency floor, not the design reserve.

6. Separation changes recovery—not the need for consistency

Separating a file blob store from the Nexus data disk can reduce the chance that artifact growth consumes application/database headroom. Separating PostgreSQL gives independent database operations. But every extra boundary creates a recovery dependency that must be documented: which backup point belongs with which blob snapshot? Which configuration recreates the repository-to-store mapping? Which credentials and IAM policies are required to read the object store?

A storage design is incomplete until its restore sequence is explainable without editing Nexus internals.

7. Keep neighboring state stores separate

8. Worked architecture decision

A 35-developer team serves Maven, npm, and Raw artifacts from one office/private cloud. It expects 300 GiB in year one, has a fast local SSD array, and can operate PostgreSQL. Its proxy cache may be rebuilt from public upstreams, but internal release content must meet a stricter recovery objective.

A defensible design is:

• External PostgreSQL for production relational state.
• One file blob store for internal authoritative hosted content and a separate file blob store for reconstructable proxy cache only if the different recovery/retention policy justifies the boundary.
• Capacity alerts well before 70–75% utilization plus the hard 4 GB emergency threshold.
• Independent but coordinated database and blob protection with a tested restore runbook.
• Repository mappings and storage assumptions recorded as configuration evidence.

Creating a separate blob store for every Maven/npm repository would add complexity without a stated failure or policy boundary.

9. Mini-lab: write a storage ADR

Write a one-page architecture decision record with these fields: workload assumptions, database choice, blob backend, repository-to-store mapping, capacity model, alert thresholds, process identity/permissions, backup dependencies, RPO/RTO assumptions, edition prerequisites, and a trigger for redesign. The acceptance criterion is that another operator can predict what fails when the database, one blob store, or the data filesystem is unavailable.

Knowledge check

10. Summary

Storage architecture is a set of operating promises: where bytes live, where metadata lives, how fast each layer must be, how much headroom exists, and how recovery reconstructs a consistent service. The next lesson turns those promises into a diagnostic sequence for realistic storage failures.

Official references and version notes

• Nexus Repository Download and 2026 self-hosted release notes — current downloadable/GA baseline.
• System Requirements — Java 21, H2/PostgreSQL guidance, file handles, disk threshold, and filesystem support.
• Database Options — embedded H2 versus external PostgreSQL.
• Directories — application and persistent data directory responsibilities.
• Storage Guide and Storage Planning — blob-store layouts, sizing, and performance implications.
• Blob Stores — blob count, used size, path, state, soft quotas, and lifecycle constraints.
• Blob Store API and REST API Reference — supported inspection/configuration endpoints.
• Change Repository Blob Store — supported Pro-only repository relocation task.
• Self-Hosted Feature Matrix — edition boundaries for storage and database capabilities.
• AWS S3 Blob Store — object-storage deployment guidance.
• Raw Repositories — hosted Raw repositories and HTTP PUT publication.

Version-sensitive statements were rechecked against Sonatype primary documentation on 2026-08-26. The current Download, versions-status, and 2026 release-notes pages list 3.94.1 as the newest GA/downloadable self-hosted line. Mandatory labs therefore pin Nexus Repository Community Edition 3.94.1-06 on loopback with Java 21 and embedded H2 only as a disposable learning database. Current system requirements recommend external PostgreSQL for supported production-scale deployments and require at least 4 GB of free disk at all times. Learners should re-check the live pages before executing the lab because Nexus support matrices evolve.