Self-Managed PostgreSQL Datasheet

Managed Postgres Locks You In. Self-Hosting Needs Fast, Durable Storage.

Managed Postgres (RDS, Cloud SQL, AlloyDB) is convenient, but it is priced per-instance, runs in the vendor's account, and gives you little control over storage, tuning, or cost at scale. Many teams would rather run PostgreSQL themselves — on VMs or as CloudNativePG on Kubernetes — inside their own cloud.

Self-hosting is only as good as the storage under it. Native cloud disks cap IOPS and throughput per instance, so Postgres stalls under OLTP load; and local NVMe is fast but ephemeral — a stopped or reclaimed instance takes the data with it.

MayaScale gives self-managed PostgreSQL a disaggregated NVMe block tier over standard NVMe-over-TCP, provisioned through the MayaScale CSI driver — sub-millisecond latency, millions of IOPS per node, per-volume QoS, active-active HA, and DR that drains volumes to a cold object pool. All inside your own account, with vanilla Postgres and no lock-in.

Benefits

Bare-metal NVMe latency for Postgres — sub-millisecond, millions of IOPS per node
Vanilla PostgreSQL — no fork, no managed-database vendor, no lock-in
Kubernetes-native — MayaScale CSI on EKS, GKE, AKS, with CloudNativePG or any operator
Ephemeral-SSD protected — active-active HA plus DR drain to a cold object pool
Runs in your own cloud — full data sovereignty

PostgreSQL on Disaggregated NVMe, via the MayaScale CSI Driver

PostgreSQL — self-hosted on VMs · CloudNativePG · Patroni · any operator

NVMe-oF / TCPCSI PersistentVolume Standard kernel nvme-tcp — no proprietary client

↓ ↓ ↓ ↓

MayaScale Block Engine Sub-millisecond · millions of IOPS/node · per-volume QoS · 8K blocks + lz4 for Postgres

Server-side RAID10 RAID1 mirror across nodes for HA · client RAID0 stripe for throughput

Bypasses cloud disk API caps Connects over the VM network — limited by bandwidth, not the per-instance disk API

Storage Node A — local NVMeRAID1 mirror

Storage Node B — local NVMeRAID1 mirror

Cold object poolS3 / Blob / GCS — DR

Manage & Deploy

MayaScale CSIEKS · GKE · AKS — PVCs for Postgres

CloudNativePGor Patroni / self-hosted on VMs

TerraformDeploy as code · Marketplace

CLI & GUImayacli · mayagui · REST

Production PostgreSQL storage, your own cloud

MayaScale provisions NVMe-over-TCP block volumes for PostgreSQL through a Kubernetes CSI driver — so self-hosted databases and CloudNativePG clusters get sub-millisecond block storage, HA, and DR to cold object storage, without a managed-database vendor and without the per-instance disk caps of native cloud disk.

Vanilla PostgreSQL, Your Way

Run stock PostgreSQL — self-managed on VMs, or as CloudNativePG / Patroni on Kubernetes. Nothing proprietary in the database path, no fork, no managed-DB vendor. When you later want instant branches and cold-tier parking, Zettabranch adds them on the same MayaScale engine — but it is entirely optional.

MayaScale CSI — Postgres Volumes on EKS, GKE, and AKS

The CSI driver provisions NVMe-oF block volumes as PersistentVolumes for your Postgres pods. A single StorageClass pool parameter names the backend; volumes are tuned for Postgres with an 8K block size and lz4 compression. Dynamic provisioning, VolumeSnapshots and writable clones for backups and dev/test, online expansion, and per-volume QoS.

NVMe Performance for OLTP

Server-side RAID10 delivers millions of IOPS per node at sub-millisecond latency, over the VM network rather than the capped cloud disk API. Postgres OLTP throughput scales with the instance, network, and number of storage nodes and clients you choose — without hitting the per-instance cloud disk ceiling that stalls native-disk databases.

Active-Active HA and Durability

A 2-node RAID1 mirror keeps databases online through drive and node failure, with automatic failover and multipath continuity. Snapshots, writable clones, and encryption at rest and in transit round out data protection — without stopping the database.

DR — Drain Postgres Volumes to a Cold Object Pool

Local NVMe is fast but ephemeral. MayaScale replicates to a cold pool on standard object storage (S3 / Blob / GCS) for DR, and the mayascale-drain service evacuates the database's volumes to that cold pool before a planned shutdown or scale-in — then rehydrates on restart. Your Postgres data survives instance stop and termination.

Ephemeral-SSD protection — drain and rehydrate to the cold object pool

Architecture & Data Services

Sub-msNVMe-over-TCP block latency for Postgres

NVMe-oFNetwork-attached — bypasses per-instance cloud disk caps

Scale-outThroughput grows with added storage nodes and clients

PostgreSQL on MayaScale	Description
Database	Stock PostgreSQL — self-managed on VMs, or CloudNativePG / Patroni on Kubernetes. No fork, no managed-DB vendor.
MayaScale CSI driver	Provisions NVMe-oF block PersistentVolumes on Amazon EKS, Google GKE, Azure AKS, and self-managed Kubernetes.
Postgres-tuned volumes	8K volume block size with lz4 compression by default; StorageClass `pool` parameter selects the backend.
Network-attached performance	Served over the VM network (NVMe-oF/TCP), so throughput scales with bandwidth instead of the per-instance cloud disk cap.
Server-side RAID10	RAID1 mirror across storage nodes for HA; client-side RAID0 stripe for aggregate throughput.
Per-volume QoS	IOPS / throughput guardrails per StorageClass, enforced below Postgres for noisy-neighbor isolation.
Snapshots & clones	CSI VolumeSnapshots and writable clones for backups, PITR staging, and dev/test copies.
Online expansion	Grow database volumes in place without downtime.
Active-Active HA	Both nodes serve traffic; automatic failover with multipath continuity.
DR to cold object pool	Automatic replication to a cold pool on standard object storage (S3 / Blob / GCS) for disaster recovery.
Drain to cold pool	`mayascale-drain` evacuates database volumes to the cold object pool before planned shutdown or scale-in, then rehydrates on restart — ephemeral NVMe data survives stop and termination.
Encryption	At rest and in transit.
Data sovereignty	Runs on standard cloud VMs in your own account; data stays on your storage nodes and buckets, never a vendor backend.
Optional: branching	Zettabranch adds instant, copy-on-write database branches and cold-tier parking on the same MayaScale engine — when you want it.

Programs & Partnerships

Available on Amazon Web Services, Microsoft Azure, and Google Cloud Marketplace, and via Terraform. sales@zettalane.com