Metadata and artifact data layers

Data separation

User, authorization, repository and artifact metadata, lifecycle, task, scan projections, audit, and operation records live in PostgreSQL. Artifact files and original SBOM bytes remain in the selected storage component; original-SBOM access requires the separate ViewRawSbom permission and audit evidence.

Operational requirement

The two data layers require consistent but separate backup, restore, capacity, health, and access plans.

Consistency model

PostgreSQL stores artifact ownership, state, checksum, size, and storage reference, while filesystem or S3 stores byte content. If the two layers are not reconciled at the same recovery point, missing metadata, orphan objects, or unavailable artifacts can result.

PostgreSQL plan

The target environment must document database version, TLS, credential source, Flyway migration permission, connection-pool budget, backup interval, and restore test. As replica count grows, multiply pool values per pod and retain headroom for administration and maintenance connections.

• The chart does not install the database; it expects externally managed PostgreSQL and a pre-created Secret.
• Check Flyway migration state in startup and health evidence; the application rollout must not receive traffic over a failed migration.
• Audit, Package Usage, Operation, and Outbound log tables use monthly UTC partitions; retention is managed separately per table and partition maintenance runs under a shared PostgreSQL lease.

Storage plan

For S3, define bucket, region, endpoint and path-style behavior, credential rotation, object lifecycle, and capacity alerts. For filesystem, define shared mount, RWX semantics, inode and space monitoring, permissions, and archive directory.

• Every application replica seeing the same byte content for the same object key
• Health and readiness surfacing target-storage and PostgreSQL outages
• Joint validation of ingress, temporary-disk, and storage limits for large packages
• Source and target capacity plus rollback ownership for cleanup archive and storage transfer
• When moving to S3, retaining the old filesystem dependency until target-component testing, the product storage-transfer workflow, and sample package reads are complete

Support-log storage boundary

Separate from artifact storage, the chart defines a 20 GiB RWX support-log claim by default. Each pod writes to its own directory and the Support bundle aggregates visible replica logs. An S3 artifact deployment still needs this small shared claim for a complete multi-replica bundle; emptyDir provides neither persistence across pod replacement nor aggregation.

Backup and restore boundary

A complete public runbook coordinating PostgreSQL, artifact storage, and raw SBOM data is not yet available. Before production approval, the organization must provide dated test evidence for write quiescence, snapshot order, secret or KMS access, restore reconciliation, and sample checksum validation.

Recovery acceptance criteria

After restore, reconcile repository and artifact counts, metadata state, storage references, checksums, and sample native-client downloads. Also verify task and audit history remains available and that new publish, scan, and cleanup operations work.

Code and live-application validation — August 3, 2026

At current source commit 943c2c6, Flyway, JDBC sessions, PostgreSQL log partitions, the storage-readiness probe that performs a real write and delete, Local and S3 backends, storage transfer, and Support bundle implementations were inspected; the targeted backend suite covering health, storage, leases, partitions, support, and identity and proxy services passed 31 of 31 tests. On the live kubaba.s3t.co environment, overall, readiness, liveness, database, migrations, and storage reported UP, and both Local and S3 components displayed ACTIVE and UP. This evidence confirms the running data and management surface; it does not prove coordinated backup and restore, recovery into an empty environment, cross-replica checksums, or capacity. The page remains Evaluation guidance.