Scale Factor 100
10M rows · 1.5 GB table
pgbench
2 vCPU / 8 GB RAM
1–100 clients × 1–8 threads
Single instance · no HA
ap-southeast-3
⚠ RDS t3 = burst window
An e-commerce platform migrating from managed cloud to on-premises Kubernetes raised a
critical question: can self-managed PostgreSQL match managed service performance after tuning?
This benchmark compares a single CNPG instance on bare metal against
single-instance RDS Standard and Aurora (t3.large) — same 2 vCPU / 8 GB RAM
allocation, same region (ap-southeast-3), no read replicas or Multi-AZ.
⚠ Note: RDS Standard uses a t3.large (burstable) instance.
Our ~50 minute total benchmark ran within the burst window — results reflect peak burst performance.
In production workloads running continuously 24/7, performance will drop once CPU credits exhaust
(t3.large baseline CPU = 30%). For sustained production comparison, consider
m6i.large or m7g.large (non-burstable).
13,955
Peak Read TPS
RDS Standard · 10c/4t · single instance
1,780
Bare Metal Write TPS
CNPG Final · beats Aurora IO-Opt
0.391 ms
Best Write Latency
Bare metal · CPU/NUMA + HugePages
Average Read-Only TPS avg across all 13 client/thread combos · higher = better
Aurora Standard
☁ Managed
CNPG Tuning 2 (NUMA+HP)
⚙ Bare Metal
CNPG Tuning 1 (CPU/NUMA)
⚙ Bare Metal
CNPG Longhorn 2R+shared
⚙ Bare Metal
CNPG Longhorn 1R
⚙ Bare Metal
CNPG Local SSD
⚙ Bare Metal
CNPG Longhorn 2R
⚙ Bare Metal
Average Read-Write TPS avg across all 13 client/thread combos · higher = better
CNPG Tuning 2 (NUMA+HP)
⚙ Bare Metal
CNPG Tuning 1 (CPU/NUMA)
⚙ Bare Metal
Aurora Standard
☁ Managed
CNPG Local SSD
⚙ Bare Metal
CNPG Longhorn 1R
⚙ Bare Metal
CNPG Longhorn 2R
⚙ Bare Metal
CNPG Longhorn 2R+shared
⚙ Bare Metal
Full Tuning Journey — Storage → CPU/NUMA → HugePages
①
Longhorn 2R (baseline)
712 RW TPS · 14.04 ms
Distributed storage · 2 replicas
→
②
Local SSD
1,425 RW TPS · 7.02 ms ▲100%
Direct-attached SSD · no network hop
→
③
+ CPU/NUMA Pinning
1,659 RW TPS · 1.81 ms* ▲22%
KVM NUMA strict · vCPU pinned · perf governor
→
④
+ HugePages
1,706 RW TPS · 1.78 ms* ▲3%
vm.nr_hugepages=8192 · K8s Guaranteed QoS · huge_pages=on
💡
3-layer tuning stack: KVM hypervisor (NUMA strict, vCPU pin, locked memory) →
VM OS (HugePages pre-alloc, perf governor) → Kubernetes (Guaranteed QoS, hugepages-2Mi resource).
Each Longhorn replica adds ~3.5ms write latency. NUMA pinning eliminates cross-NUMA penalty —
write latency at 1 client drops from 7.02ms → 1.81ms (-74%).
* Latency at 1 client.
Average TPS Summary avg across all 13 client/thread combos · disaggregated by workload type
AWS RDS (t3.large)
10,724
2,250
4,826 — Burstable ⚠
AWS Aurora (IO-Prov.)
8,370
1,234
3,480 — Expensive
CNPG Tuning 2 (NUMA+HP) ⚡
7,232
3,351 — #3 Overall ⚡
AWS Aurora Standard
8,039
1,162
3,326 — Standard
CNPG Tuning 1 (CPU/NUMA)
6,896
3,214 — Strong
CNPG Longhorn 2R+shared
7,052
2,885 — -34% RW vs SSD
CNPG Longhorn 1R
6,376
2,797 — -15% RW vs SSD
CNPG Local SSD
6,111
2,796 — Baseline
CNPG Longhorn 2R
6,356
2,671 — -31% RW vs SSD
RW bars show write-only avg — the most relevant metric for OLTP. Read avg is similar across all bare metal configs. Overall avg includes RO+RW+TPC-B and is dominated by read volume. ⚠ RDS Standard (t3.large) is burstable — its 4,826 overall avg reflects burst window performance (~50 min benchmark). In 24/7 production, performance drops once CPU credits exhaust. CNPG Tuning 2's 3,351 is consistent regardless of duration.
Environment Key
CNPG Local SSD — CloudNativePG on bare metal, Samsung SM863a SAS direct-attached
CNPG Longhorn 1R/2R — Same bare metal host, Longhorn distributed storage (1 or 2 replicas)
RDS Standard — AWS RDS PostgreSQL 17.6, t3.large (burstable — benchmark ~50 min within burst window; 24/7 production performance lower once credits exhaust)
Aurora IO-Opt / Standard — AWS Aurora PostgreSQL 17.4, t3.large
