Blob Stores, Storage Layout, Database Choices, Capacity Planning, and Data Separation: Concepts, Architecture, and Mental Model

1. The storage problem: a repository is not one directory

Chapter 04 established that hosted, proxy, and group repositories define where requests are written and read. Chapter 05 asks a different question: what durable state makes those repositories work? If an operator answers “the Nexus folder,” backup, migration, capacity, and incident decisions become dangerous because several independent state stores are being collapsed into one mental bucket.

A component such as a JAR, npm tarball, OCI layer, or Raw file must have bytes somewhere. Nexus also needs records that say which repository owns the asset, its path and format metadata, security and repository configuration, and other product state. Those responsibilities do not live in the same place.

2. Six locations that beginners often confuse

The blob store is broader than “large binaries.” A repository protocol can store metadata and checksum files as assets too. Conversely, the database is not a container for all artifact bytes. Recovery succeeds only when the database/configuration state and blob content agree.

3. Application directory versus data directory

The application directory is the unpacked Nexus software distribution. The data directory is the persistent working area. Upgrading normally introduces a new application distribution while preserving/migrating persistent state according to the supported upgrade procedure. Copying a fresh application directory does not restore repositories; copying only a data subdirectory does not necessarily restore an external PostgreSQL database.

4. H2 and PostgreSQL solve the same role at different operating scales

New self-hosted installations currently use embedded H2 by default, but Sonatype documents clear H2 limits and recommends external PostgreSQL for deployments beyond small/disposable use. This is a database choice, not a package-format choice.

Do not combine these limits with Community Edition licensing/usage limits. Database supportability and product edition limits are separate dimensions.

5. File and object blob stores are storage backends, not repository types

A repository—Raw hosted, Maven proxy, npm group, and so on—references a blob store. Multiple repositories can use the same blob store. A file blob store places blob data on a filesystem path accessible to the Nexus process. An object blob store uses a supported cloud backend such as S3 under the current edition/support matrix.

Object storage can improve capacity elasticity and durability characteristics, but it adds API/network latency, IAM policy, region placement, provider limits, and new failure modes. Sonatype’s guidance favors locating object storage in the same cloud/region as Nexus; it is not a drop-in replacement for a low-latency embedded database filesystem.

6. Capacity planning is more than summing package sizes

Sonatype’s storage-planning model approximates blob usage as the combined component bytes plus filesystem overhead. A useful first-order expression is:

\[\text{blob capacity} \approx \sum \text{component bytes} + 1.5N\times \text{filesystem block size}\]

That is only the blob portion. Operators also reserve room for the data directory, temporary work, logs, database growth, cleanup/compaction behavior, upgrades, backups, and growth between capacity-review cycles. Current system requirements require at least 4 GB available disk at all times; below that threshold the database switches to read-only. An SLO should alert much earlier than the emergency boundary.

7. IO, file handles, ownership, and filesystem support are integrity controls

Nexus performance is frequently bounded by disk and network IO rather than CPU. The embedded database needs responsive storage; blob storage needs reliable throughput and capacity. The dedicated Nexus OS account must be able to access the intended data/blob paths. Sonatype also requires higher file-handle limits on Linux/macOS and warns that exhausting file descriptors can lead to data loss.

“The mount exists” is not sufficient evidence that it is supported for every Nexus state type. Current system requirements distinguish embedded-data support from blob-store support across local filesystems, network filesystems, and object storage. Verify the exact matrix before choosing a production mount.

8. Read-only inspection before mutation

Capture three independent views: product state, storage mapping, and operating-system capacity. The following calls do not edit Nexus state.

# POSIX/Bash. Use only against the disposable loopback instance.
LAB="$HOME/nexus-ch05-lab"
NX_URL="http://127.0.0.1:8081"
mkdir -p "$LAB/evidence" "$LAB/payload" "$LAB/move"
umask 077
read -rsp "Disposable Nexus admin password: " NX_PASS; printf "\n"
printf 'machine 127.0.0.1 login admin password %s\n' "$NX_PASS" > "$LAB/nexus.netrc"
unset NX_PASS
NETRC="$LAB/nexus.netrc"

# Never print, commit, or reuse this temporary credential file.

curl -fsS "$NX_URL/service/rest/v1/status"   | tee "$LAB/evidence/01-status.txt"

curl --fail-with-body --silent --show-error --netrc-file "$NETRC"   "$NX_URL/service/rest/v1/blobstores"   | tee "$LAB/evidence/02-blobstores.json"

curl --fail-with-body --silent --show-error --netrc-file "$NETRC"   "$NX_URL/service/rest/v1/repositorySettings"   | tee "$LAB/evidence/03-repository-settings.json"

# POSIX: inspect the filesystem that actually contains the Nexus data directory.
df -h "$HOME" | tee "$LAB/evidence/04-disk.txt"
rm -f "$NETRC"
unset NETRC

Also record the database mode from the supported Nexus System Information/Support view. Do not open the H2 database files to “prove” that H2 is in use.

9. Why this matters in DevOps

Artifact availability, build throughput, retention, recovery time, and upgrade safety all depend on storage architecture. A pipeline can be perfectly configured and still fail if the database becomes read-only, a blob volume has no headroom, object-store latency grows, or a backup contains only half of the state graph. Storage design therefore belongs in the service’s architecture decision records, capacity dashboard, backup runbook, and incident evidence.

Knowledge check

10. Summary

Nexus storage is a coordinated state system, not a folder of packages. The next lesson creates disposable blob stores and repositories, measures real growth, and proves exact-byte transfer without touching internal database or blob files.

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.