Best VPS for Database Hosting in 2026 — Top 5 Tested & Ranked

The Query That Took 340ms on SATA and 12ms on NVMe

Last October I was migrating a client's e-commerce backend from a "premium SSD" VPS to a new provider. The database was PostgreSQL 16, roughly 4GB total with a 1.8GB working set. Nothing exotic — a products table with 2.3 million rows, a orders table with 8.7 million rows, and the usual constellation of junction tables for categories, tags, and inventory tracking.

Before the migration, I ran EXPLAIN (ANALYZE, BUFFERS) on the query that powered their main product search page:

EXPLAIN (ANALYZE, BUFFERS)
SELECT p.id, p.name, p.price, p.slug,
       COUNT(o.id) as order_count
FROM products p
LEFT JOIN order_items oi ON oi.product_id = p.id
LEFT JOIN orders o ON o.id = oi.order_id
  AND o.created_at > NOW() - INTERVAL '30 days'
WHERE p.category_id = 47
  AND p.status = 'active'
GROUP BY p.id
ORDER BY order_count DESC
LIMIT 24;

On the old provider — a well-known host marketing "SSD storage" that turned out to be SATA SSD behind a RAID controller — this query consistently ran in 340ms. The BUFFERS output told the story: 4,218 shared buffer hits, but 1,847 reads. Those 1,847 pages were not in the buffer pool and had to come from disk. At the SATA controller's 14K random read IOPS and ~0.18ms average latency per read, those pages took roughly 330ms to fetch. The actual computation — the join, the aggregation, the sort — took about 10ms.

After migrating the identical database (same pg_dump, same postgresql.conf, same indexes, same shared_buffers = 1GB) to a Hetzner CX22 with NVMe storage, the same query ran in 12ms. The buffer output showed nearly identical numbers — 4,230 shared hits, 1,812 reads — but each of those reads completed in microseconds instead of fractions of a millisecond. NVMe's 52K IOPS at ~0.005ms latency per read turned those 1,812 page fetches from a 330ms operation into a 9ms operation.

The indexes were identical. The configuration was identical. The data was identical. The query plan was identical. The only variable was the storage medium underneath. Storage latency is query latency. This is the fact that every VPS review glosses over while comparing Geekbench scores.

I have seen this pattern repeat across dozens of migrations since. The ratio varies — sometimes it is 5x, sometimes 30x, depending on how much of the working set fits in the buffer pool — but the conclusion never changes: for database workloads, the disk under your data is the single most important specification on the VPS.

The Buffer Pool Math Nobody Teaches You

Every database tuning guide says "give your buffer pool 70-80% of RAM" for MySQL or "set shared_buffers to 25% of RAM" for PostgreSQL. But almost none of them explain why those numbers exist or help you calculate whether your specific workload actually fits in the buffer pool. Here is the math that actually matters.

MySQL InnoDB Buffer Pool Sizing

The InnoDB buffer pool caches both data pages and index pages. The rule of thumb — innodb_buffer_pool_size = 70-80% of total RAM — exists because the remaining 20-30% needs to cover the OS, the MySQL server process itself (connection threads, sort buffers, tmp tables), and any other services running on the box. On a dedicated database VPS, you can push to 80%. On a shared app+database server, stay at 60-70%.

But the real question is: does your working set fit? Here is how to check:

-- Check your total InnoDB data + index size
SELECT
  ROUND(SUM(data_length + index_length) / 1024 / 1024, 0) AS total_mb,
  ROUND(SUM(data_length) / 1024 / 1024, 0) AS data_mb,
  ROUND(SUM(index_length) / 1024 / 1024, 0) AS index_mb
FROM information_schema.tables
WHERE engine = 'InnoDB';

-- Check buffer pool hit ratio (should be > 99%)
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_read%';

If Innodb_buffer_pool_reads (disk reads) divided by Innodb_buffer_pool_read_requests (total read requests) is greater than 1%, your buffer pool is too small. Every percentage point above 1% means a measurable increase in average query latency.

PostgreSQL shared_buffers and the OS Cache Trick

PostgreSQL's memory model is different from MySQL's. The shared_buffers setting at 25% of RAM is intentionally conservative because PostgreSQL relies heavily on the operating system's filesystem cache for the remaining reads. The OS cache automatically holds recently-accessed pages, so PostgreSQL effectively gets a two-tier caching system: shared_buffers for the hottest data, and the OS cache for everything else.

This is why PostgreSQL's recommendation is 25% rather than 70-80%. The OS cache uses the remaining free RAM (after shared_buffers, work_mem, maintenance_work_mem, and the OS itself). Setting shared_buffers to 75% of RAM on PostgreSQL would actually hurt performance because it steals memory from the OS cache, creating double-buffering overhead.

-- Check PostgreSQL cache hit ratio
SELECT
  sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS cache_hit_ratio
FROM pg_statio_user_tables;

-- Should be > 0.99 for a well-sized buffer pool

RAM Allocation Table by VPS Size

Here is exactly how I allocate RAM on every database VPS I configure. These numbers come from years of production tuning, not from a defaults file:

The "Max Working Set" column is what matters. If your hot data exceeds that number, your database will constantly evict pages from the buffer pool to make room for new ones, and every eviction means a future disk read. This is the cliff edge where IOPS becomes life or death. Below the cliff, even a mediocre storage backend feels fast. Above it, only NVMe saves you.

Use our VPS size calculator to figure out which plan matches your database's working set. And if you are not sure how big your working set is, here is the rule I use: it is roughly 20-30% of your total database size for most OLTP applications. A 10GB database typically has a 2-3GB working set that needs to live in RAM.

pgbench Results: The Only Benchmark That Matters

I am tired of VPS reviews that run Geekbench and call it a day. Geekbench tells you how fast your CPU can multiply matrices. It tells you nothing about how fast your database can commit a transaction. For that, you need pgbench — the benchmark tool that ships with PostgreSQL and tests actual database operations: INSERTs, UPDATEs, SELECTs, and transaction commits against real tables with real indexes.

I ran pgbench on all five providers with identical configurations: PostgreSQL 16, shared_buffers = 1GB, wal_buffers = 64MB, checkpoint_completion_target = 0.9, scale factor 100 (roughly 1.6GB dataset), 8 clients for the baseline test and 16 clients for the stress test. Each test ran for 300 seconds to capture steady-state performance, not burst behavior.

Read-Only Results (SELECT-heavy workload)

Read-Write Results (mixed INSERT/UPDATE/SELECT)

A few things jump out from these numbers:

• UpCloud and Hostinger trade blows on write performance. UpCloud's MaxIOPS delivers the lowest p99 latency (18.7ms), which means fewer tail-latency spikes for your users. Hostinger edges ahead on raw TPS (1,950 vs 1,890). If your users feel the p99 more than they feel the median — and they do — UpCloud wins the write battle.
• Hetzner punches above its price. At $4.59/mo, delivering 5,840 TPS read-only is remarkable. That is 91% of UpCloud's throughput at 19% of the cost for a comparable RAM plan. For read-heavy workloads (most web applications), Hetzner's value per dollar is untouchable.
• The read-write gap tells you about WAL performance. Every write in PostgreSQL hits the WAL (Write-Ahead Log) before confirming the transaction. WAL writes are sequential, but they still need to fsync to disk. The difference between Hostinger's 1,950 TPS and DigitalOcean's 1,380 TPS is almost entirely explained by WAL commit latency — which is, again, a storage performance metric.
• p99 latency is where cheap storage dies. Average latency looks acceptable on most providers. But p99 — the latency that 1 in 100 of your users experiences — varies by 67% between the best (UpCloud at 18.7ms) and worst (DigitalOcean at 31.2ms). That tail latency compounds when your application makes multiple database calls per page load.

See the full benchmarks page for raw fio and sysbench data across all 33 providers we test.

#1. Hetzner — Best Overall for Databases

I keep coming back to a simple question when ranking database VPS providers: if I had one client with a 2GB PostgreSQL working set, a $10/mo budget, and zero tolerance for query latency spikes, where would I put them? The answer has been Hetzner for three consecutive quarters now.

The CX22 plan costs $4.59/mo. For that you get 2 vCPU, 4GB RAM, and 40GB NVMe. That 4GB RAM means innodb_buffer_pool_size = 2.8GB on MySQL or shared_buffers = 1GB with ~2.5GB of effective OS cache on PostgreSQL. A 2GB working set lives comfortably in memory, and the 52K IOPS NVMe underneath handles the cold reads without stalling.

# postgresql.conf on Hetzner CX22 (4GB RAM)
shared_buffers = 1GB
effective_cache_size = 3GB
work_mem = 16MB
maintenance_work_mem = 256MB
wal_buffers = 64MB
checkpoint_completion_target = 0.9
random_page_cost = 1.1  # NVMe is fast enough to lower this
effective_io_concurrency = 200
max_connections = 100
max_worker_processes = 2

The reason Hetzner lands at #1 is not any single spec but the RAM-to-price ratio. Most providers charge $20-24/mo for 4GB RAM. Hetzner gives you the same for $4.59. For database workloads where RAM determines how often you hit disk, that pricing gap translates directly into performance per dollar. Private networking is included free, snapshots run $0.012/GB/month, and cloud-init lets you automate the entire provisioning pipeline.

Two US datacenter locations (Ashburn and Hillsboro) is the main constraint. If your application lives in Dallas or Atlanta, the network round trip to Ashburn adds 20-35ms to every query. For applications co-located on the same Hetzner VPS or connected via private networking in the same datacenter, this is a non-issue.

pgbench at a Glance

Why Database Admins Choose Hetzner

• 52K IOPS on NVMe — handles heavy read/write workloads without queueing
• 4GB RAM at $4.59/mo — the best buffer pool per dollar in the industry
• Private networking included free for app-to-database connections
• Cloud-init support for automated database provisioning
• Automated snapshots for point-in-time server recovery ($0.012/GB)

Where Hetzner Falls Short

• Only 2 US datacenter locations (Ashburn and Hillsboro)
• Snapshots cost extra — not included in base price
• No managed database service — you configure and maintain everything
• Email-only support with no live chat for urgent database emergencies

#2. UpCloud — Fastest MaxIOPS Storage

Most VPS providers buy commodity NVMe drives, slot them into servers, and call it a day. UpCloud did something different: they built their own distributed storage layer called MaxIOPS from scratch, striping data across multiple NVMe drives with built-in redundancy. The result is not just high IOPS — it is consistent IOPS. And for databases, consistency beats peaks every single time.

Here is why consistency matters more than you think. During a PostgreSQL checkpoint, the database flushes dirty pages from shared_buffers to disk. On a standard single-NVMe setup, this creates an I/O storm that temporarily degrades read performance. Your users see this as a latency spike every few minutes. On UpCloud's MaxIOPS layer, the checkpoint writes distribute across the stripe, and reads continue hitting different physical drives. In my 300-second pgbench runs, UpCloud's p99 latency was 18.7ms — the lowest of any provider. That means fewer tail-latency spikes for your end users.

The tradeoff is price. UpCloud's entry plan ($7/mo) only includes 1GB RAM and 25GB storage — barely enough for a toy database. To get the 4GB RAM you need for a real buffer pool, you are looking at $24/mo. That is 5x the cost of Hetzner for similar RAM. But if your workload is write-heavy and I/O consistency under load is more important than monthly cost — think high-throughput OLTP, real-time analytics, heavy INSERT workloads with concurrent reads — that MaxIOPS layer justifies the premium.

Private networking is free, and their US locations in New York, Chicago, and San Jose give you three geographic options. For multi-region setups with read replicas, UpCloud's API makes it straightforward to automate provisioning across datacenters.

Key Specs

Pros for Database Users

• 62K MaxIOPS with lowest I/O variance — checkpoint storms barely register
• Redundant distributed storage protects against drive failures without performance loss
• Lowest p99 latency in read-write pgbench (18.7ms)
• 3 US datacenter locations with free private networking
• Hourly billing for spinning up dev/test database environments

Cons to Consider

• $24/mo for 4GB RAM — 5x Hetzner's cost for similar specs
• Smaller community and fewer tutorials than DigitalOcean or Hetzner
• 25GB storage on the base plan is unusable for real databases
• No managed database add-on — fully self-managed

#3. Hostinger — Highest Raw IOPS

If you only care about one number, it is this: 65K IOPS. Hostinger's NVMe storage delivered the highest raw I/O performance in every fio test I ran. For write-heavy databases — INSERT-heavy workloads, replication targets, applications that generate large WAL volumes — that write IOPS number (55K) is what keeps transaction commit latency low.

I want to explain why write IOPS specifically matters here, because read IOPS gets all the attention. Every time PostgreSQL commits a transaction, it writes to the WAL and calls fsync(). Every time MySQL commits, InnoDB writes to the redo log and syncs. The time between "transaction committed in memory" and "fsync confirmed by disk" is your commit latency. At 55K write IOPS, Hostinger completes those syncs faster than any other provider on this list. In the pgbench read-write test, Hostinger hit 1,950 TPS at 16 clients — the highest raw throughput I measured.

At $6.49/mo you get 4GB RAM and 50GB NVMe on the KVM 1 plan. The 50GB is generous — 25% more than Hetzner's 40GB — which gives you breathing room for WAL archives and temporary files that database operations generate. Where Hostinger falls short is in the areas around the database: no private networking for multi-server setups, and the AI-assisted control panel, while helpful for beginners, cannot replace proper CLI access for serious database tuning.

I tested something specific on Hostinger that I did not test elsewhere: sustained write performance over 30 minutes. Some providers throttle IOPS after an initial burst period. Hostinger's 65K IOPS held steady throughout the entire test window, dropping to 61K at the 25-minute mark and recovering. No throttling. That matters for ETL jobs, bulk imports, and migration scenarios where you are writing continuously for extended periods.

# Sustained write test I ran on Hostinger KVM 1
fio --name=sustained_write --ioengine=libaio --direct=1 \
    --rw=randwrite --bs=4k --numjobs=4 --iodepth=32 \
    --size=4G --runtime=1800 --time_based \
    --group_reporting

# Results (averaged over 30 min):
# IOPS: avg=63,847 min=58,210 max=65,124
# lat (usec): avg=198.42, p99=412.80
# No throttling detected

Hostinger vs Hetzner: The $1.90 Question

The $1.90/mo premium buys you 25% more IOPS and 25% more storage. If writes are your bottleneck, Hostinger is worth the extra cost. If reads dominate (most web applications), Hetzner's cost-per-TPS advantage makes it the better deal.

Cons to Consider

• No private networking — database traffic traverses the public network unless you use SSH tunnels or WireGuard
• 50GB NVMe fills up fast with WAL archives on a busy write-heavy database
• No managed database service — entirely self-managed
• Control panel is designed for beginners, which means limited advanced configuration options

#4. ScalaHosting — Best Managed Option

Not everyone wants to be a DBA. If the words innodb_buffer_pool_size make your eyes glaze over and you would rather focus on building your application than tuning checkpoint_completion_target, ScalaHosting exists so you do not have to care.

Here is a story that illustrates the value. A solo founder running a SaaS product contacted me last year because his PostgreSQL database was "randomly slow." He was on an unmanaged VPS. The issue turned out to be autovacuum running on his largest table during peak hours, combined with shared_buffers still set to the default 128MB on a 4GB server. Two configuration changes fixed it completely. But those two changes took me — someone who does this for a living — about 15 minutes to diagnose. It would have taken him days of Googling. ScalaHosting's support team handles exactly this type of issue.

Their SPanel includes one-click MySQL and PostgreSQL setup with sane defaults (they actually set innodb_buffer_pool_size based on your plan's RAM, which is more than most panels do), automated daily backups, and monitoring that alerts you before your disk fills up. The SShield security system handles patching automatically, which eliminates the "I forgot to update PostgreSQL and got owned" scenario that hits unmanaged servers every few months.

The raw numbers are respectable — 58K IOPS and a 4100 CPU score — but not chart-topping. At $29.95/mo it costs 6.5x more than Hetzner for the same RAM. The question is whether the managed support, automated backups, and security monitoring save you more than $25/mo in time and risk. If you are running a production e-commerce database and a slow query costs you sales, paying for managed support is cheaper than hiring a DBA. If you are a developer who knows postgresql.conf by heart, you are overpaying.

Key Specs

Cons to Consider

• $29.95/mo is 6.5x the cost of Hetzner for similar RAM and storage
• SPanel is proprietary — if you outgrow it, migration requires effort
• Only US East datacenter location limits geographic flexibility
• No hourly billing — monthly minimum commitment even for testing

#5. DigitalOcean — Best for Managed Databases

DigitalOcean is the only provider on this list that lets you skip self-hosting entirely. Their Managed Databases product handles MySQL, PostgreSQL, MongoDB, and Redis with automated failover, daily backups, end-to-end encryption, and zero-downtime version upgrades. You point your application at a connection string and never touch postgresql.conf again.

I ran the same pgbench suite against a DigitalOcean Managed PostgreSQL instance ($15/mo, 1 vCPU, 1GB RAM, 10GB storage) and compared it to self-hosted PostgreSQL on a $6/mo Droplet (1 vCPU, 1GB RAM, 25GB NVMe). The results are interesting:

The managed instance is 25% slower on raw throughput and costs 2.5x more. But it includes automated failover (standby node promotes in <60 seconds), daily backups with point-in-time recovery, built-in connection pooling, and automatic minor version upgrades. For teams without database expertise — or teams that have it but would rather spend it on application code — the managed option eliminates an entire category of operational risk.

Where DigitalOcean really shines is the ecosystem around the database. VPC private networking connects your Droplets to your managed database over a private network. Their Docker and Kubernetes support integrates cleanly with database connection strings. And their documentation is the best in the industry — their PostgreSQL optimization series taught me the random_page_cost trick I now use on every NVMe server.

If you self-host on Droplets instead of using managed databases, the raw IOPS (55K) and CPU (4000) are middle-of-the-pack. The $6/mo Droplet is a solid choice if you know what you are doing. But DigitalOcean earns its spot on this list specifically because of the managed database option that no other provider here offers at this quality level.

Key Specs (Self-Hosted Droplet)

Pros for Database Users

• Only provider with production-grade Managed Databases (MySQL, PostgreSQL, MongoDB, Redis)
• Automated failover with standby node promotion in under 60 seconds
• Best documentation and tutorials in the VPS industry, especially for databases
• VPC private networking for secure database connections at sub-1ms latency
• 8 US datacenter locations — the widest geographic coverage on this list

Cons to Consider

• 55K IOPS on self-hosted Droplets trails Hetzner, UpCloud, and Hostinger
• Managed database starts at $15/mo for 1GB RAM — premium pricing for small projects
• Managed databases are 25% slower than self-hosted due to abstraction overhead
• Basic Droplets only include 25GB NVMe storage

Choose Your Database Engine by Workload

The "best VPS for databases" depends on which database you are running. MySQL, PostgreSQL, MongoDB, Redis, and SQLite each stress different resources in different proportions. Running MongoDB on a 1GB VPS is a recipe for OOM kills. Running Redis on a SATA SSD is pointless because Redis barely touches disk. Here is the decision matrix I use when recommending VPS plans to clients:

A Note on SQLite in Production

SQLite is having a moment. Tools like Litestream and LiteFS have made it viable for production web applications by solving the replication and backup problems. If you are running a single-server application (which is most applications), SQLite eliminates the entire connection overhead and query serialization layer. On a high-IOPS VPS like Hostinger, a WAL-mode SQLite database can handle thousands of reads per second with sub-millisecond latency. The cheapest VPS options actually work well for SQLite because it has minimal RAM requirements — all it needs is fast disk.

A Note on Redis Persistence

If you use Redis purely as a cache (no persistence), literally any VPS with enough RAM works. But if you enable RDB snapshots or AOF persistence, IOPS suddenly matters because Redis forks a child process to write the dump. On a VPS with slow storage, this fork+write can block the main Redis thread for seconds on large datasets. For persistent Redis, choose UpCloud or Hostinger for their consistent write IOPS.

The Backup Strategy That Actually Works

I have recovered databases from backups more times than I want to admit. Corrupted WAL after a power event. Accidental DROP TABLE in production (yes, by a senior engineer). Ransomware that encrypted the data directory. Every one of those incidents would have been catastrophic without a working backup. And by "working," I mean "tested within the last 30 days." A backup you have never restored is a backup you do not have.

Here is the three-layer approach I deploy on every database VPS. Each layer catches different failure modes:

Layer 1: VPS Provider Snapshots (Disaster Recovery)

Provider snapshots capture the entire server state — OS, configuration, data, everything. If your server dies, you restore the snapshot to a new instance and you are running in minutes. The downside: snapshots are point-in-time, so you lose everything between the last snapshot and the failure.

• Hetzner: $0.012/GB/month, manual or API-triggered
• UpCloud: Included free, automated schedule available
• Hostinger: Weekly automated snapshots included free
• ScalaHosting: Daily automated snapshots included free
• DigitalOcean: $0.05/GB/month (20% of Droplet cost), weekly automated

Layer 2: Database-Native Dumps (Logical Backup)

Logical dumps (mysqldump, pg_dump) create portable SQL files that you can restore to any server, any version, any provider. They are slower than snapshots but more flexible. Store them off-server — in object storage, on a different VPS, or both.

# MySQL: Daily compressed backup to /backup, keep 7 days
# Add to crontab: crontab -e
0 3 * * * mysqldump -u root --single-transaction --routines \
  --triggers --all-databases | gzip > \
  /backup/mysql-$(date +\%Y\%m\%d).sql.gz && \
  find /backup -name "mysql-*.sql.gz" -mtime +7 -delete

# PostgreSQL: Daily compressed backup, keep 7 days
0 3 * * * pg_dump -U postgres -Fc --compress=9 mydb > \
  /backup/pg-$(date +\%Y\%m\%d).dump && \
  find /backup -name "pg-*.dump" -mtime +7 -delete

# Upload to object storage (S3-compatible)
30 3 * * * aws s3 sync /backup/ s3://my-db-backups/ \
  --storage-class STANDARD_IA --delete

Layer 3: WAL Archiving / Binary Logs (Point-in-Time Recovery)

This is the layer most people skip and the layer you will wish you had when someone runs DELETE FROM orders WHERE 1=1 at 2 PM and your last dump was at 3 AM. WAL archiving (PostgreSQL) or binary log replication (MySQL) captures every transaction as it happens. Combined with a base backup, you can restore to any point in time — down to the second.

# PostgreSQL WAL archiving (add to postgresql.conf)
archive_mode = on
archive_command = 'gzip < %p > /wal_archive/%f.gz'
wal_level = replica

# MySQL binary log retention (add to my.cnf)
[mysqld]
log_bin = /var/log/mysql/mysql-bin
binlog_expire_logs_seconds = 604800  # 7 days
binlog_format = ROW

The total cost of this three-layer approach on Hetzner is roughly $1-3/mo for snapshot storage plus a few GB of object storage for off-site dumps. On providers with free snapshots (UpCloud, Hostinger, ScalaHosting), the only additional cost is the object storage for off-site copies. That is insurance you cannot afford to skip. For more details on backup-friendly providers, see our backup VPS guide.

Database VPS Comparison Table

Pricing Breakdown: Database-Ready Plans

For database hosting, you want at least 4GB RAM and 40GB+ NVMe storage. Here is what each provider charges for a database-appropriate plan, along with the cost per pgbench TPS — the metric that actually predicts your database performance per dollar:

Hetzner's $0.0028 per read-write TPS is 4.5x better than UpCloud and 7.2x better than ScalaHosting. If your budget is the primary constraint and you are comfortable managing PostgreSQL or MySQL yourself, there is no mathematical argument for any other provider. The premium options justify their cost through consistency (UpCloud), managed support (ScalaHosting), or managed databases (DigitalOcean) — but not through raw performance per dollar.

How I Tested (and What I Deliberately Skipped)

I deployed PostgreSQL 16 and MySQL 8.0 on each provider's nearest 2 vCPU / 4GB RAM plan. I did not run Geekbench or any generic CPU test. Instead, I ran the benchmarks that a DBA would actually care about — the ones that correlate with real query latency:

• fio random read/write: 4K block size, queue depth 32, direct I/O. This measures raw IOPS and latency percentiles (p50, p99, p999) under conditions that mimic real database access patterns. I ran each test for 300 seconds to capture steady-state behavior, not burst.
• pgbench (read-only and read-write): Scale factor 100 (~1.6GB dataset), 8 and 16 clients, 300-second runs. This is the gold standard for PostgreSQL benchmarking because it tests actual transaction processing including WAL commits.
• sysbench OLTP: 10 tables, 1M rows each, 16 threads. Measures transactions per second with a realistic read/write mix on MySQL. Catches contention issues that single-threaded tests miss.
• Sustained write test: 30-minute continuous random write at 4K block size. Detects IOPS throttling that providers hide behind burst allocations.
• Checkpoint impact test: pgbench running during forced checkpoints. Measures how much read performance degrades when the database flushes dirty pages to disk.

I deliberately did not weight CPU single-thread scores in the rankings. For OLTP workloads, IOPS and RAM are 10x more predictive of real performance than CPU benchmarks. See the full benchmarks page for raw data across all 33 providers we test.

Frequently Asked Questions