Bare Metal vs. AWS RDS: A Deep Dive into NUMA-Aware Tuning and PostgreSQL Performance

A real-world comparison across 7 environments, same workload, same hardware class, zero guesswork.

When a client asked whether self-managed PostgreSQL on bare metal Kubernetes could replace their AWS RDS setup, I didn't want to answer based on intuition. So we ran the benchmarks ourselves — methodically, across seven environments, with the same scale factor and the same hardware class throughout.

This article documents what we found, including a tuning discovery that cut baseline latency by 56% without changing a single piece of hardware.

The Setup: 32-Core NUMA-Aware Beast

To keep the comparison fair, all environments (Bare Metal vs Cloud) were allocated 2 vCPU / 8 GB RAM.

However, there is a fundamental difference in the underlying "Metal." Our bare metal node is a powerhouse:

• 32 Cores (16 Physical Cores / 16 Hyper-Threading)


• NUMA-Aware Architecture


• Local SSD SAS Storage

Unlike Cloud VMs (t3.large) that run on a hypervisor with "noisy neighbors," our Bare Metal allows the PostgreSQL process to talk directly to physical cores and dedicated memory banks. This is why "2 vCPU" on Bare Metal is not the same as "2 vCPU" in the Cloud.

1. The Benchmark Results (Average TPS)

After multiple iterations across the full matrix, here is the final average performance leaderboard:

2. Peak Read-Only TPS (Maximum Reads)

Maximum read throughput achieved across all client/thread combinations:

RDS Standard leads on raw reads, but the 75% gap between CNPG ① and ③ (on the same physical hardware) proves that configuration is just as critical as the underlying metal.

3. Peak Read-Write TPS (Maximum Writes)

Result: Tuned bare metal beats both Aurora variants. Aurora's write path involves distributed storage replication, which adds latency. Our NUMA-aware physical cores combined with local SSD SAS proved superior for raw write throughput.

4. The Tuning Discovery That Changed Everything

CNPG Local ① started with poor performance: 1,116 TPS (0.896 ms latency).

Step 1: Solving Memory Contention (Tuning ②)

We reduced work_mem (32MB -> 4MB) and max_connections (800 -> 200).

The Math: 800 connections × 32MB = 25.6GB potential RAM pressure on an 8GB node. This caused constant swapping. By capping connections, the system stabilized.

Result: 2,402 TPS (115% improvement).

Step 2: Maximizing Buffer Pool (Tuning ③)

We increased shared_buffers to 6GB and utilized HugePages, leveraging our host's direct memory access and NUMA affinity.

Result: Latency dropped to 0.394 ms.

① 0.896 ms ████████████████████████

② 0.416 ms ███████████

③ 0.394 ms ██████████

56% latency reduction. Same hardware.

5. Final Verdict: Performance vs. Cost Efficiency

"While RDS Standard showed higher peak TPS due to the burstable nature of the t3.large instance, it comes with a significantly higher price tag and unpredictable long-term performance once CPU credits are exhausted. For consistent production workloads where cost-efficiency is a priority, CNPG on Bare Metal is the clear winner—delivering 70% of the performance at 1/10th of the cost."

The Burstable CPU Trap

AWS t3 instances rely on a credit-based system. Once those credits are gone, performance drops. Our 32-Core Bare Metal gives you Dedicated Resources. No CPU credits, no "noisy neighbors." You get 100% of the CPU, 100% of the time.

The ROI Factor

Our Bare Metal host (IDCloudHost Paket 13) has 512GB RAM. On AWS, a 512GB RAM instance would cost a fortune. On Bare Metal, we can host dozens of high-performance clusters on this one machine for a flat rate of ~Rp 7M/mo.

Key Takeaways

1. 
   Storage is Everything: Our tests with Longhorn showed a massive performance drop. For databases, local SSD SAS tuning is non-negotiable.


2. 
   The "Cloud Tax" is Real: You are paying a massive premium for the "Managed" label. With CNPG, managing Postgres on K8s becomes viable and much cheaper.


3. 
   Know Your Workload: If you have unpredictable spikes, RDS burst capacity is great. But for a stable, high-traffic system, Bare Metal is the foundation.


4. 
   Default Config is the Enemy: The interaction between work_mem and max_connections is non-linear. Never trust the defaults.


5. 
   Bare Metal is Not Inherently Slower: Properly tuned, we achieved 69% of RDS's write throughput on owned hardware.


6. 
   Aurora's Write Path Overhead: Distributed storage optimizes for durability and read scale-out, not raw single-node write speed.


7. 
   Storage Choice = Config Choice: Longhorn vs. local-path is a 33-50% difference. The storage backend deserves as much attention as the DB config.

Environment Details

• 
  CloudNativePG: v1.24 on K8s 1.31


• 
  Host: Bare Metal 32-Core (16 Physical/16 HT), NUMA-Aware


• 
  AWS Region: ap-southeast-3 (Indonesia)


• 
  Scale Factor: 100 (10M Rows)

— Iwan Setiawan, Hybrid Cloud & Platform Architect · portfolio.kangservice.cloud