# Storage Model (/docs/runtime/storage-model)



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

Structured Operational State [#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 [#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 [#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 [#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.