PostgreSQL Benchmark: AWS RDS vs Hostim vs Self-Hosted on Hetzner (2026) | HOSTIM.DEV

Skip to main content<br>Short answer first: at the same size (2 vCPU / 4 GB, PostgreSQL 16), Hostim had the fastest writes , about 2.5× the write throughput of AWS RDS db.t4g.medium and 2.1× a default self-hosted Postgres on Hetzner. Hetzner had the fastest reads , on raw per-core CPU speed. RDS was slowest or near-slowest on both , and its listed price is the smallest part of the real bill.

This post shows every number, the exact commands to reproduce them, and (because it changes the conclusion) what high availability actually costs on each platform.

Benchmarks run July 2026 on PostgreSQL 16, in a central-Europe region. Prices change often, so check each provider's live pricing page before you commit. The shape of the result changes far less than the exact numbers.

What we compared​

Three ways to run a small production Postgres, all at 2 vCPU / 4 GB RAM, PostgreSQL 16 , in a central-Europe region:

OfferingInstanceListed price / monthReplicated (failover)?Hostim managed Postgresdrp-50 (2 vCPU / 4 GB)€50Yes, by default AWS RDSdb.t4g.medium (2 vCPU / 4 GB)~$48 (instance only)No (single-AZ)Self-hostedHetzner CPX22 (2 vCPU AMD / 4 GB, shared)€19.49No (single node)<br>The "replicated" column matters a lot for both price and performance. It gets its own section below.

Methodology​

The goal was a like-for-like test, not a flattering one. The rules:

Same DB size: 2 vCPU / 4 GB on every target.

Same Postgres major version: 16.

A separate load generator per target , one network hop from the database, in the same region, never on the database box itself. Each client had 4 vCPU so the client was never the bottleneck (checked with mpstat).

Same workload: pgbench, scale factor 50 (about 750 MB, which fits in RAM so the test measures CPU and the commit path, not cold disk reads), 300-second runs.

Client setup:

sudo apt-get install -y postgresql-contrib nmap sysstat # pgbench + nping<br>pgbench --version

The workload, run identically against each database:

# initialise (~750 MB)<br>pgbench -i -s 50

# write-heavy, TPC-B-like, 4 clients, 5 minutes<br>pgbench -c 4 -j 4 -T 300

# read-only, 8 clients, 5 minutes<br>pgbench -c 8 -j 4 -T 300 -S

# single connection, write, 1 minute (isolates commit/fsync latency)<br>pgbench -c 1 -T 60

Network latency was measured with a TCP ping to port 5432 (nping --tcp -p 5432) and a SELECT 1 round-trip, because ICMP is not open on every platform.

Configuration parity, stated plainly: the self-hosted Hetzner node ran stock Postgres defaults (shared_buffers 128 MB, no tuning). That is the realistic "install Postgres and go" baseline. RDS ran on its default parameter group, which AWS tunes for the instance size. Hostim runs its own managed tuning. In other words, the two managed options are tuned out of the box and the self-hosted default is not, and that difference is part of what you are comparing.

Results​

All runs completed with zero failed transactions .

Write throughput (4 clients, TPC-B)​

TargetTPSAvg latencyHostim drp-50 2,708 1.48 msHetzner (default)1,3033.07 msAWS RDS t4g.medium1,0803.71 ms<br>Hostim did about 2.5× the write throughput of RDS and 2.1× the default Hetzner node.

Single-connection write latency (1 client)​

This isolates the commit path. Every transaction waits for a WAL flush (synchronous_commit = on is the default), so it mostly measures storage fsync latency.

TargetTPSAvg latencyHostim drp-50 871 1.15 msAWS RDS t4g.medium4162.41 msHetzner (default)2763.63 ms<br>Both self-hosted and RDS pay for network-attached block storage on the commit path. This is the single biggest driver of the write-throughput gap.

Read throughput (8 clients, SELECT-only)​

TargetTPSAvg latencyHetzner (default) 20,068 0.40 msHostim drp-5014,3330.56 msAWS RDS t4g.medium13,2610.60 ms<br>Reads scale with CPU, and the Hetzner box took this one on raw per-core AMD speed with no orchestration layer in the path. Hostim and RDS were close, with RDS last. Note that db.t4g.medium is a burstable instance: over a sustained 300-second run it can drop to its CPU-credit baseline, which is what the ~$48 tier is designed to provide. A workload that needs sustained CPU would move to an m-class RDS instance, which costs roughly twice as much.

Network latency​

TargetTCP RTT (avg)SELECT 1Hostim drp-500.48 ms~0.29 msHetzner (default)0.71 ms~0.39 msAWS RDS t4g.medium1.50 ms~0.58 ms

The price you actually pay​

This is where the listed numbers stop being useful.

AWS RDS: $48 is not the bill​

The ~$48 is the instance only , single-AZ, on-demand. On top of that you pay, metered separately:

Storage : gp3 is billed per GB-month.

IOPS and throughput above the gp3 baseline: billed if you provision more.

Backups : retained backup storage beyond your volume size is billed.

Data transfer : egress and cross-AZ traffic are billed per GB.

One storage dropdown makes this concrete. Pick Provisioned IOPS SSD in the create-database wizard and...