Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket intends to offer VMs, managed databases, Kubernetes clusters, object storage, and application hosting.
Those products all depend on storage, but until now the architecture has only explicitly covered object storage through Objekt. The platform still needs a coherent baseline for block storage, persistent volumes, backup, and cross-datacenter recovery expectations.
Without this ADR, VM runtime selection, Kubernetes service design, and database lifecycle design remain underspecified.
Decision
Dataverket treats storage as a first-class platform domain with three distinct classes:
Object storage S3-compatible storage owned by Objekt.
Block storage Persistent volumes for VMs, databases, and Kubernetes workloads.
Shared filesystem or equivalent shared data service Only for products that explicitly require shared file semantics.
The v1 platform must define all three classes conceptually, but only object storage and block storage are mandatory for the initial product set.
Storage ownership model
Storage ownership is split as follows:
- Objekt owns object storage lifecycle and policy
- Maskin consumes block storage for VM disk lifecycle
- Plattform consumes block storage through CSI-backed persistent volume workflows
- Database services consume block storage and define higher-level data durability behavior
- Sentral owns storage inventory, allocation metadata, and dependency tracking
No single service should claim to “own storage” in the abstract. The platform must distinguish between storage infrastructure, storage allocation, and product-specific data lifecycle.
Block storage baseline
The v1 platform requires a block-storage strategy that can support:
- VM root and data disks
- PostgreSQL and other managed database volumes
- Kubernetes PersistentVolume claims through CSI
- backup and restore workflows
- inventory visibility for capacity, placement, and attachment state
The specific backend remains open for now, but the control-plane contract must assume that block storage exists as a managed resource, not as an ad hoc side effect of local disks.
That openness should not be deferred until VM, database, or Kubernetes delivery is already underway. A block-storage selection-criteria ADR and an initial backend shortlist should be produced early enough to constrain runtime, provisioning, and platform-service design before those phases are implementation-bound.
Kubernetes persistence baseline
Plattform must expose persistent storage through a CSI-compatible model.
This means:
- Kubernetes persistence is not hand-managed per cluster
- persistent volume classes must map to platform-defined storage capabilities
- storage class behavior must be explicit to operators and tenants
The first version does not need a large catalog of storage tiers, but it must have a real persistent volume story.
VM persistence baseline
VM products require explicit disk lifecycle management.
That means the platform must model:
- boot disk creation
- optional additional data disks
- snapshot or backup hooks
- recovery or recreation behavior
- disk placement and attachment visibility
The first VM product must not depend on undocumented hypervisor-local storage semantics alone.
Data durability model
Dataverket must distinguish between:
availability Whether a workload or storage resource is currently reachable
durability Whether data survives node, host, or site loss
recovery How data is restored after failure
The platform must not imply that compute failover alone provides data durability.
Multi-datacenter implications
Because Dataverket is explicitly multi-datacenter, storage design must be honest about what cross-site behavior is supported.
The v1 baseline is:
- not all stateful products are automatically cross-site replicated
- site failover claims must state whether data is synchronously replicated, asynchronously replicated, backed up only, or not replicated at all
- storage recovery behavior must be explicit per product class
This ADR does not declare a universal cross-datacenter storage technology. It requires that failover language and data durability language stay aligned.
Inventory and API implications
Storage must appear in inventory and APIs as real resources or capabilities.
The platform should be able to represent at least:
- storage pools or classes
- allocated volumes
- attachment relationships
- capacity and placement metadata
- backup and recovery metadata where applicable
Operational baseline
The first storage-capable platform release must support:
- provisioning visibility
- capacity visibility
- backup visibility
- failure visibility
- operator workflows for restore and recovery
Storage that cannot be observed or recovered is not an acceptable foundation for tenant-facing products.
Explicit non-decisions for now
This ADR intentionally does not yet choose:
- a specific block-storage backend
- a specific shared-filesystem backend
- synchronous versus asynchronous replication technology
- final backup tooling
Those require follow-up ADRs once storage platform candidates have been evaluated.
The non-decision is about final selection, not about whether evaluation happens early. Candidate narrowing and selection criteria belong in the early architecture phase, not only in the later storage delivery phase.
Consequences
- storage is no longer an implicit afterthought inside VM and Kubernetes design
- VM, database, and Kubernetes products now have a shared persistence baseline
- future failover claims must be tied to actual storage behavior
- backend selection work is still required before implementation is complete
- storage evaluation must start before metal and platform-service implementation become coupled to accidental defaults
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- This ADR supports the product and architecture assumptions in platform-plan.md.
- The tenancy and inventory implications depend on 009-resource-inventory-and-tenancy-model.md.
- Any VM runtime choice in 011-vm-runtime-selection.md must fit this persistence model.
- Multi-datacenter recovery claims must stay aligned with 012-inter-datacenter-topology-and-failover.md.
More Information
- block-storage platform selection criteria
- first block-storage backend shortlist
- CSI and storage class strategy
- backup and restore model
- database storage and replication strategy
- VM disk replication and recovery strategy
Audit
- 2026-03-14: ADR proposed.