Storage Model

Runtime uses more than one storage pattern because platform services do not all need the same kind of persistence.

Structured Operational State

PostgreSQL is used for structured, transactional, and queryable platform data.

This is the right fit for:

• service state
• metadata
• configuration data
• workflow and authorization persistence

PgAdmin complements this model by giving operators a direct management and inspection interface for PostgreSQL.

Object and artifact storage

Rook-Ceph provides the primary S3-compatible object storage layer through its RADOS Gateway (RGW) endpoint. It also exposes CephFS for shared file storage.

This is the right fit for:

• files and binary assets
• platform artifacts
• buckets shared by workloads
• data that is not naturally relational

Platform components that consume S3 storage (MLflow, Milvus, Kubeflow Pipelines, Argo Workflows, Tempo) connect to the Rook Ceph RGW endpoint.

Model cache volumes

CSI S3 provides a specialized storage path for AI model weights. It uses the AWS Mountpoint S3 CSI driver to mount Rook Ceph S3 buckets as local filesystem volumes inside Kubernetes pods.

KubeAI uses CSI S3-mounted volumes to access pre-downloaded model weights from object storage. This avoids duplicating large model files across nodes and reduces inference pod startup time.

Why the separation matters

Using multiple storage models keeps the Runtime layer cleaner:

• relational storage is used where consistency and queries matter
• object storage is used where artifacts and large binary objects matter
• CSI-mounted S3 volumes bridge the gap between object storage and workloads that need filesystem access

This makes Runtime more flexible for the higher layers that build on top of it.