AWS RDS for PostgreSQL vs ServersCamp managed PostgreSQL: pgbench TPC-B

Comparative benchmark of managed PostgreSQL across two providers. May 2026.

The same numbers as bars below. AWS leads on bench100 (in-cache, where only CPU matters); ServersCamp T2 leads on bench1000 and bench10000 (where storage starts to dominate). The grouping at bench100 - where all three bars are within ~6% of each other - is essentially CPU-generation noise.

Latency tracks TPS in mirror image - more transactions per second means lower per-transaction latency. The gap on bench10000 (disk-bound) is what later in the article shows up as p95 latency cut roughly in half for ServersCamp T2.

Test standtop

Equipment overview

Client VM (pgbench generator)

Methodologytop

Principles

• Out of the box - no ALTER SYSTEM, no custom parameter groups, no tuning. The provider's default is the product.
• Identical pgbench parameters on both sides: -c 32 -j 4 -M prepared --no-vacuum.
• Three database sizes, covering different regimes:
  • scale=100 (~1.5 GB) - fits entirely in page cache, measures CPU and locks.
  • scale=1000 (~15 GB) - partial cache, mixed CPU + disk.
  • scale=10000 (~150 GB) - disk-bound, random IO dominates.
• Three runs per size. Before each run: CHECKPOINT + wait for autovacuum to finish.
• Warmup before the series: 5 min for bench100/1000, 10 min for bench10000.
• Measurement: 10 min for bench100/1000, 20 min for bench10000.
• --log --aggregate-interval=10 - TPS/latency captured every 10 seconds for stability analysis.

1. Environment

Set once per shell session on each pgbench client VM. Connection details below are anonymised; substitute your own RDS endpoint and ServersCamp managed-PG endpoint from the respective control panels.

AWS EC2 client

export PGHOST="<your-instance>.eu-central-1.rds.amazonaws.com"
export PGPORT="5432"
export PGUSER="postgres"
export PGPASSWORD='<your-password>'
export PGSSLMODE="require"

ServersCamp VM client

export PGHOST="postgres-<id>.apps.serverscamp.com"
export PGPORT="5432"
export PGUSER="<your-user>"
export PGPASSWORD='<your-password>'
export PGSSLMODE="require"

Both sides use PGSSLMODE=require so encryption overhead is comparable. Default libpq settings otherwise - no statement timeouts, no client-side pooling, no application_name games.

2. Creating the test databases and loading data

One-time setup before the run scripts. pgbench -i -s N creates the four standard pgbench tables and loads N×100k accounts. Wrap the bench10000 init in screen or tmux - it takes ~26 minutes on AWS, ~38 minutes on the slowest ServersCamp config.

AWS

psql -d postgres <<'SQL'
CREATE DATABASE bench100;
CREATE DATABASE bench1000;
CREATE DATABASE bench10000;
SQL

time pgbench -d bench100   -i -s 100
time pgbench -d bench1000  -i -s 1000
time pgbench -d bench10000 -i -s 10000

ServersCamp

Same shape. Note that on ServersCamp the per-tenant user does not have access to the maintenance postgres database; the platform provisions a default database per user (here db_<id>) which we connect to for DDL.

psql -d db_<id> <<'SQL'
CREATE DATABASE bench100;
CREATE DATABASE bench1000;
CREATE DATABASE bench10000;
SQL

time pgbench -d bench100   -i -s 100
time pgbench -d bench1000  -i -s 1000
time pgbench -d bench10000 -i -s 10000

Before Test 2 on ServersCamp (after raising storage QoS from 5k/225 to 12k/500), drop and recreate to measure init from a clean slate:

psql -d db_<id> <<'SQL'
DROP DATABASE IF EXISTS bench100;
DROP DATABASE IF EXISTS bench1000;
DROP DATABASE IF EXISTS bench10000;

CREATE DATABASE bench100;
CREATE DATABASE bench1000;
CREATE DATABASE bench10000;
SQL

time pgbench -d bench100   -i -s 100
time pgbench -d bench1000  -i -s 1000
time pgbench -d bench10000 -i -s 10000

3. Run script

Same structure for all three scenarios. Only the database name, the warmup duration, and the measurement duration change.

bench100 - AWS variant

settle() {
  echo "[$(date +%H:%M:%S)] CHECKPOINT + waiting for autovacuum..."
  psql -d postgres -c "CHECKPOINT;" >/dev/null
  while [ "$(psql -d postgres -tAc "SELECT count(*) FROM pg_stat_activity WHERE backend_type='autovacuum worker'")" != "0" ]; do
    echo "  autovacuum still working..."
    sleep 10
  done
  echo "[$(date +%H:%M:%S)] ready"
}

mkdir -p ~/results/aws/bench100 && cd ~/results/aws/bench100

settle
echo "=== WARMUP ==="
pgbench -d bench100 -c 32 -j 4 -T 300 -M prepared --no-vacuum

for i in 1 2 3; do
  settle
  echo "=== RUN $i ==="
  pgbench -d bench100 -c 32 -j 4 -T 600 -M prepared --no-vacuum \
    --log --log-prefix=run${i} --aggregate-interval=10 \
    2>&1 | tee run${i}.txt
done

echo "=== DONE bench100 ==="

bench100 - ServersCamp variant

Identical to the AWS version, except settle() uses psql -d bench100 (the per-tenant user does not have access to postgres), and results live under ~/results/serverscamp/bench100:

settle() {
  echo "[$(date +%H:%M:%S)] CHECKPOINT + waiting for autovacuum..."
  psql -d bench100 -c "CHECKPOINT;" >/dev/null
  while [ "$(psql -d bench100 -tAc "SELECT count(*) FROM pg_stat_activity WHERE backend_type='autovacuum worker'")" != "0" ]; do
    echo "  autovacuum still working..."
    sleep 10
  done
  echo "[$(date +%H:%M:%S)] ready"
}

mkdir -p ~/results/serverscamp/bench100 && cd ~/results/serverscamp/bench100

settle
echo "=== WARMUP ==="
pgbench -d bench100 -c 32 -j 4 -T 300 -M prepared --no-vacuum

for i in 1 2 3; do
  settle
  echo "=== RUN $i ==="
  pgbench -d bench100 -c 32 -j 4 -T 600 -M prepared --no-vacuum \
    --log --log-prefix=run${i} --aggregate-interval=10 \
    2>&1 | tee run${i}.txt
done

echo "=== DONE bench100 ==="

bench1000

Same structure. Only changes:

• Database name: bench100 → bench1000 everywhere (including in settle() on the ServersCamp side).
• Output folder: ~/results/{aws,serverscamp}/bench1000.
• Same warmup (5 min, -T 300) and same measurement (10 min, -T 600) as bench100.

bench10000

Same structure, but longer runs because cold-cache disk-bound TPS takes longer to stabilise:

• Database name: bench10000.
• Output folder: ~/results/{aws,serverscamp}/bench10000.
• Warmup: 10 min (-T 600) instead of 5.
• Measurement: 20 min (-T 1200) instead of 10.

# settle() identical, paste from above

mkdir -p ~/results/aws/bench10000 && cd ~/results/aws/bench10000   # or /serverscamp/

settle
echo "=== WARMUP ==="
pgbench -d bench10000 -c 32 -j 4 -T 600 -M prepared --no-vacuum

for i in 1 2 3; do
  settle
  echo "=== RUN $i ==="
  pgbench -d bench10000 -c 32 -j 4 -T 1200 -M prepared --no-vacuum \
    --log --log-prefix=run${i} --aggregate-interval=10 \
    2>&1 | tee run${i}.txt
done

echo "=== DONE bench10000 ==="

4. What settle() does

Called before warmup and before every measurement run - never skipped, never reused. Two steps:

1. CHECKPOINT - forces the server to flush all dirty shared buffers to disk. Without this, an in-flight checkpoint started by the previous run can leak IO contention into the current measurement.
2. Poll pg_stat_activity every 10 seconds until no autovacuum worker backends are running. Autovacuum competes for the same CPU and IO as pgbench - measuring while it's working would understate steady-state TPS.

Note: on the ServersCamp side, settle() connects to the bench database itself (e.g. psql -d bench100) rather than to a maintenance database, because the per-tenant user does not have access to the postgres DB. pg_stat_activity is server-wide, so the count of autovacuum workers is the same regardless of which DB you connect from.

5. pgbench parameters - identical on both sides

6. Output files

After each scenario, ~/results/{provider}/{benchN}/ contains:

• runN.txt - the pgbench summary printed at the end of run N: TPS, latency average, transactions processed, failed transactions. This is what we copy into the article body and the comparison tables.
• runN.<PID> and runN.<PID>.1, runN.<PID>.2, runN.<PID>.3 - per-thread aggregate logs (4 files per run, one per -j worker). Each line is a 10-second window with timestamp, transaction count, latency mean/min/max. These feed the stability analysis later in the article.

All of the above - run scripts, raw runN.txt summaries, and per-interval aggregate logs from every run - is checked in at github.com/serverscamp/pgbench-aws-vs-serverscamp. Clone it, run the same scripts on your own AWS RDS and ServersCamp accounts, and verify any number in this article.

Two ServersCamp configurations - read this

ServersCamp goes through the full benchmark cycle twice with different storage QoS, deliberately, to isolate how much of the disk-bound result is storage-driven vs database-driven. The current ServersCamp default storage tier is 10,000 IOPS / 500 MB/s; both Test configurations bracket that.

Everything else - vCPU, RAM, PG version, pg_hba - is the same across both. CPU and RAM on both ServersCamp runs are identical.

Init phase: loading datatop

pgbench -i -s N loads the test tables. It's not part of the TPS run, but it gives a baseline sense of disk and CPU throughput under sequential pressure.

Init results

Excerpts from init logs (bench10000)

AWS RDS

done in 1561.67 s (drop tables 0.00 s, create tables 0.01 s,
  client-side generate 876.29 s, vacuum 1.59 s, primary keys 683.78 s).
real    26m1.711s

ServersCamp T1 (5k IOPS)

done in 2280.92 s (drop tables 0.00 s, create tables 0.02 s,
  client-side generate 1337.61 s, vacuum 5.95 s, primary keys 937.32 s).
real    38m1.080s

ServersCamp T2 (12k IOPS)

done in 1479.85 s (drop tables 0.00 s, create tables 0.01 s,
  client-side generate 941.12 s, vacuum 3.33 s, primary keys 535.40 s).
real    24m39.970s

Storage bottleneck, demonstrated

Disk Throughput readings from the ServersCamp panel during PK build:

In both cases, the disk hits its ceiling - at 225 MB/s on Test 1, at 500 MB/s on Test 2. So Test 1's storage QoS really is the bottleneck, and ServersCamp's managed-PG is capable of consuming the same 500 MB/s as AWS gp3.

pgbench runs: TPS and latencytop

bench100 (~1.5 GB, in-cache, CPU-bound)

Database fits in shared_buffers + page cache entirely. We're measuring CPU and locks. Storage shouldn't matter.

What this measures in practice. This is not a typical production scenario - real databases rarely fit entirely in 8 GB of RAM. What we're effectively isolating here is the gap between two CPU generations (Ice Lake vs Skylake), not anything about how the database is managed or how storage is provisioned. AWS's lead is silicon, not architecture. Useful as a control measurement, but if you're choosing a managed-PG provider for a real workload, this row tells you almost nothing about what you'll actually get.

The raw pgbench output below is included for transparency - the table summarises it, but if you want to verify the numbers yourself, here it is. The two lines that actually matter are tps = ... (transactions per second, the headline number) and latency average = ... (mean per-transaction latency). Everything else describes the run setup. Full run.txt for every run of every scenario, plus the per-interval aggregate logs, lives in the repo: github.com/serverscamp/pgbench-aws-vs-serverscamp.

pgbench summary, AWS Run 2

pgbench (18.3)
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: prepared
number of clients: 32
number of threads: 4
duration: 600 s
number of transactions actually processed: 2380108
number of failed transactions: 0 (0.000%)
latency average = 8.065 ms
initial connection time = 143.238 ms
tps = 3967.670593 (without initial connection time)

ServersCamp Test 2 Run 1

pgbench (18.3 (Ubuntu 18.3-1.pgdg24.04+1))
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 100
query mode: prepared
number of clients: 32
number of threads: 4
duration: 600 s
number of transactions actually processed: 2246325
number of failed transactions: 0 (0.000%)
latency average = 8.545 ms
initial connection time = 183.938 ms
tps = 3744.748138 (without initial connection time)

bench1000 (~15 GB, partial cache)

Database ~15 GB on ~8 GB available cache. Some pages get read from disk - storage starts to matter.

What this measures in practice. This is the regime smaller production systems actually live in: DB a few times bigger than RAM, hot pages cached, cold pages on disk. Both CPU and storage influence the result, which makes this the noisiest scenario - run-to-run variance jumps to 5-8% as cache warmth and autovacuum timing shift between runs. Useful as a transition view between "all in cache" and "all on disk", but for buying decisions the bench10000 row below carries more weight.

Especially telling: Run 3 (with cache fully warm):

• AWS Run 3: 2,883.51 TPS
• ServersCamp T2 Run 3: 2,884.13 TPS

Difference: 0.02% - statistical noise. With a warm cache the two providers run identically.

Raw pgbench output for that warm-cache run, side by side. Compare the tps and latency average lines - the rest is metadata.

AWS Run 3

scaling factor: 1000
duration: 600 s
number of transactions actually processed: 1729727
latency average = 11.098 ms
tps = 2883.514321 (without initial connection time)

ServersCamp Test 2 Run 3

scaling factor: 1000
duration: 600 s
number of transactions actually processed: 1730230
latency average = 11.095 ms
tps = 2884.131092 (without initial connection time)

bench10000 (~150 GB, disk-bound)

Database ~150 GB on 8 GB RAM - most of it cold. Every transaction takes a page miss and goes to disk. The scenario closest to a real production workload.

What this measures in practice. This is what production looks like for any database past the small-side: tens or hundreds of GB on a host with 8-16 GB RAM, hot set bigger than cache, page miss on most transactions. Storage characteristics and managed-PG overhead dominate the result - the CPU advantage AWS had on bench100 gets neutralised because the workload spends most of its time waiting for disk anyway. If you're picking between providers, this row is the one to weight most heavily. It's also where the stability difference (CoV, latency tails) shows up clearly.

Raw pgbench output, mid-series run on each side. Look at tps: ServersCamp processed ~265,000 more transactions in the same 1200-second window, with lower average latency. Same workload, same client, same connection settings - the difference is on the database side.

AWS Run 3

scaling factor: 10000
duration: 1200 s
number of transactions actually processed: 2807282
latency average = 13.677 ms
tps = 2339.689575 (without initial connection time)

ServersCamp Test 2 Run 3

scaling factor: 10000
duration: 1200 s
number of transactions actually processed: 3073180
latency average = 12.493 ms
tps = 2561.339411 (without initial connection time)

Stability and latency tails: the real findingtop

Median TPS is only part of the picture. Reading the per-interval logs (TPS/latency every 10 s via --aggregate-interval=10) revealed a qualitative difference between the providers that the summary numbers hide.

1. Within-run stability (CoV TPS)

Coefficient of Variation = stdev(TPS_per_interval) / mean(TPS) × 100%. Smaller = more uniform performance during the run.

2. TPS dips - minimum over a 10-second window

Across three bench10000 runs, AWS dropped to 700-1000 TPS in individual 10-second windows (nearly -70% from the mean). Without direct EBS/RDS telemetry we can't pin the mechanism - candidates: checkpoint stalls flushing dirty pages, multi-tenant noisy neighbours on EBS, periodic internal RDS-agent activity. ServersCamp T2 didn't show comparable dips in the same runs - TPS stayed in a narrow band.

Note on gp3: unlike gp2, gp3 has no burst credits - it's a steady provisioned baseline by spec. So calling these dips "gp3 burst exhaustion" would be technically wrong. Whatever's causing them is on the AWS side, but without EBS CloudWatch metrics we won't claim more than that.

3. Latency tails: p95 of average latency over 10-second windows

Important note on the metric. This is not p95 latency over individual transactions. This is p95 of "average latency in a 10-second window" across 60-120 windows per run. With --aggregate-interval=10, the per-transaction distribution wasn't recorded. For real per-transaction p99/p999 you'd need a separate run with --log and no aggregation.

4. bench10000 summary (real-world, disk-bound)

ServersCamp T2 isn't just 9% faster on the median - it's qualitatively more stable on disk-bound work. Vendors don't usually publish numbers like these because they spoil the sleekness of marketing-grade benchmarks.

Sidenote: top and Performance Insightstop

You can skip this section - it's loose observations from the server side without strong interpretation. Including it because the numbers are interesting; if anyone has a sharper read on the mechanism, we'd love to hear it.

Top waits on AWS RDS during bench1000/bench10000 (Performance Insights)

LWLock:WALWrite           5.82  ████████████████
IO:DataFileRead           3.61  ██████████
IO:WalSync                0.70  ██
Client:ClientRead         0.57  █
CPU                       0.54  █
Lock:transactionid        0.33  █
Timeout:VacuumDelay       0.04
IPC:ProcarrayGroupUpdate  0.03
IO:DataFileWrite          0.03
Lock:tuple                0.02

OS CPU breakdown under the same workload (bench10000)

AWS RDS

%Cpu(s):  7.2 us, 22.8 sy, 48.6 ni, 9.2 id, 10.6 wa,  0.0 hi,  1.6 si,  0.0 st

ServersCamp

%Cpu(s): 51.8 us, 32.3 sy,  0.0 ni,  0.7 id,  2.5 wa,  0.0 hi, 12.7 si,  0.0 st

What jumped out:

• On AWS, user CPU ~7%, nice ~49%. On ServersCamp, user ~52%, nice 0%.
• iowait: AWS ~10.6%, ServersCamp ~2.5%.

Adding user+nice, total CPU usage looks comparable on both sides (~52-55%). But how the kernel scheduler accounts for that work in each case - we won't try to interpret. If anyone with deeper knowledge of either provider's managed internals can explain, we'd take the comment.

Summary tabletop

TPS gap: ServersCamp Test 2 vs AWS m6i across scenarios

Storage QoS contribution (T1 → T2)

On bench100 the storage upgrade does nothing (DB in cache). On bench1000/10000 the lift is 24-27% - direct effect of higher IOPS/throughput.

Cost at this configurationtop

Same hardware spec on both sides (2 vCPU / 8 GB / 500 GiB), same EU region, on-demand pricing, no commitments. Excludes backup storage, data transfer, and support tier on both sides.

AWS prices are billed in USD; converted to EUR using the ECB reference rate of 1 USD = €0.92 as of 2026-05-05 for like-for-like comparison. Original USD figures shown in parentheses.

AWS RDS for PostgreSQL db.m6i.large

ServersCamp managed PostgreSQL db-m-8g

AWS at €205.40 is roughly 1.85× more expensive than ServersCamp at €111.36 for the same configuration on-demand.

Price per TPS (disk-bound, the production-realistic scenario)

Dividing monthly cost by median TPS on bench10000 - the scenario closest to a real production workload:

ServersCamp delivers ~2× more transactions per euro at the most production-relevant scenario. On the upcoming price update we mention in the roadmap, that gap widens further.

The honest caveat: AWS Savings Plans / Reserved Instances

Why we benchmark on-demand

The whole point of cloud is "scale up when you grow, scale down when you don't." Reserved Instances and Savings Plans break that promise - in exchange for a discount, you commit to a fixed amount of compute for 12 or 36 months.

We approached this benchmark from the pay-as-you-grow perspective because that's the model most cloud customers actually live in - startups, small SaaS teams, indie devs, and frankly the majority of teams whose next quarter's load isn't already locked in. For that reality, fixed-commitment pricing is the wrong shape:

• You don't know if next month brings 200 users or 2,000. A 1-year RI assumes you do.
• If traffic doubles tomorrow, on-demand absorbs it. A reserved instance sized for last year's load doesn't.
• If traffic dies, on-demand stops billing the moment you stop the instance. An all-upfront RI is already paid.
• "Save 60% with 3 years upfront" is a discount that applies to teams who already know exactly how much they'll need for 36 months. Most don't.

So the comparison that's relevant to our reader is on-demand vs on-demand. That's the €111.36 vs €205.40 above. RIs are an option AWS gives you, not a price you'd pay if you came in cold today.

Conclusionstop

What we proved

1. Managed PG as a product is equivalent across both providers. At identical vCPU/RAM/storage QoS, both deliver close or identical TPS on the same workload. Run 3 of bench1000 (TPS 2883.51 AWS vs 2884.13 ServersCamp T2) - 0.02% difference, perfect parity.
2. On CPU-bound workload, AWS m6i wins thanks to the newer CPU. Ice Lake 8375C edges Skylake 6132 by ~6% TPS on bench100 - within the theoretical IPC + clock advantage.
3. On disk-bound workload, ServersCamp T2 wins thanks to less managed-PG overhead. On bench10000, at storage parity ServersCamp leads by 9% TPS and cuts p95 latency roughly in half. Likely contributors: nice-priority cost on RDS, Nitro+EBS overhead, WAL contention.
4. The stability trend on disk-bound favours ServersCamp T2. Across three runs, CoV TPS ~4% vs ~23% for AWS, and we didn't see the kind of large TPS dips on T2 that AWS produced (min -15% from mean vs -68% on AWS). It's a directional signal in our sample - for a categorical claim, 10+ runs at different times of day are needed.
5. Storage QoS is the dominant lever for disk-bound work. When we ran a deliberately constrained probe (Test 1, 5k IOPS / 225 MB/s, well below the current 10k/500 default), TPS dropped 14-18% on bench1000/bench10000. Same managed-PG, same CPU, same RAM - just half the IOPS and half the throughput. Doubling them back inverts the result. This is the underlying reason AWS's "free 12k/500 baseline at 400+ GiB" is such a load-bearing detail of the comparison.
6. On the price-performance dimension, the gap is wider than the raw TPS gap. On-demand, same hardware: €111.36 (ServersCamp) vs €205.40 (AWS). Cost per TPS at disk-bound: ~€0.045 vs ~€0.090. ServersCamp delivers ~2× more transactions per euro, no commitment needed to access that price.

The pattern

The more disk-bound the workload, the more AWS's CPU advantage gets neutralised, and the more its managed-PG overhead shows up. Linear relationship:

Practical takeaway

If your DB fits in RAM - AWS m6i is ~6% faster on CPU. You pay roughly 2× the price for that ~6%. Most teams won't make that trade.

If your DB is bigger than RAM (typical production) - ServersCamp at storage parity delivers +9% TPS, half the p95 latency, ~5× lower TPS variance, and ~half the bill. That's not a marginal advantage on any single axis - it's a stack of them.

Storage QoS matters - more than CPU or memory for disk-bound work. ServersCamp's current default tier (10,000 IOPS / 500 MB/s) sits ~17% below AWS gp3's free 12k/500 baseline on IOPS, identical on throughput. In practice that lands much closer to Test 2's behaviour than Test 1's. For very large databases or read-heavy production you may want a higher tier - but the math still ends up cheaper than RDS at parity.

A note on AWS sizing - this matters. Our 150 GB database sits on a 500 GiB RDS volume on purpose. AWS gp3 starts at only 3,000 IOPS / 125 MB/s baseline; the 12,000 IOPS / 500 MB/s tier we benchmarked against kicks in for free only at 400+ GiB volumes. We sized up so the comparison would land against AWS at its free best. If you provision a smaller disk (say 200 GiB) and don't pay extra for provisioned IOPS on top, your disk-bound TPS on RDS will be substantially worse than what we measured here - and the gap to ServersCamp gets bigger, not smaller.

Bottom line

On the roadmaptop

• The same pgbench across the other major managed Postgres providers - DigitalOcean, Render, Supabase, Neon, Aiven, Crunchy Bridge. One workload, identical settings, the same disclaimer template. The point isn't to crown a winner, it's to give you a like-for-like grid you can read across.
• Price update on our managed PostgreSQL. We've already done the deeper price-per-TPS and price-per-p95 numbers on the back of this benchmark. The honest takeaway: our PostgreSQL pricing has room to come down. Expect an adjustment before the next benchmark drops - if we ask people to compare on numbers, we don't get to hide behind soft pricing.

Raw data, including per-run run.txt summaries, per-interval aggregate logs, and the run scripts, is published on GitHub: github.com/serverscamp/pgbench-aws-vs-serverscamp. The test is reproducible; if you can't reproduce it on your account, that's a writeup bug - tell us via a ticket.