Read-only queries. Writes are refused unless allowed.
Category DatabaseStack PostgreSQLJobs 16
About this PostgreSQL reads load test
Load tests PostgreSQL with read-only queries: a single-row select, count(*), an indexed lookup, a two-table join and pool saturation. Writes are refused unless you allow them, so it is safe to point at real data.
It holds 16 ready-made jobs: 5 single scenarios and an enterprise test plan of 11 stages to run in order, 9 of them with pass/fail targets (SLOs). Each job is a plain request pattern you can change before running.
Scenarios include postgres single-row select, postgres count(*), postgres indexed lookup, postgres two-table join and postgres pool saturation.
How to load test PostgreSQL reads
Open the template in BLASTA.
Check the settings so they point at your own PostgreSQL reads system, ideally a staging copy.
Pick a job and choose the rate and duration.
Start the run and watch requests per second, latency percentiles and errors live; the result is saved to your history.
Enterprise plan, step 1 of 10. One request a second for 30 seconds. Run this first, every time: it proves the address, credentials and headers are right and that the environment is up before any real load is applied. Gate: zero errors. Reference request: postgres indexed lookup.
Step 2 of 10. About a fifth of normal traffic for 5 minutes: the uncontended latency of this request. Every later result is judged against it, so record p50 and p95. Gate: at most 0.5% errors and the default latency targets. Reference request: postgres indexed lookup.
Step 3 of 10. Normal busy-hour traffic for 10 minutes. The rate is the reference job's rate: raise it to your measured production peak-hour rate. This is the run that proves (or breaks) your SLO. Gate: at most 1% errors, p95 and p99 inside the targets. Reference request: postgres indexed lookup.
Step 4 of 10. Twice the average for 10 minutes: the busiest hour of the year plus headroom. Latency may rise, but must stay in SLO; if it does not, you have no headroom. Gate: at most 2% errors, latency targets doubled. Reference request: postgres indexed lookup.
Step 5 of 10. Ramps to four times average over 10 minutes, then holds for 2. Finds where it degrades and HOW: gracefully (latency rises, errors stay low) or badly (errors, timeouts, crashes, restarts). Observation only, no gate. Reference request: postgres indexed lookup.
Step 6 of 10. Reaches ten times average within 10 seconds and holds for 2 minutes: a campaign email, a news link, a failover. Checks autoscaling, queue limits and load shedding. Gate: at most 5% errors, because shedding load is acceptable and crashing is not. Reference request: postgres indexed lookup.
Step 7 of 10. Run IMMEDIATELY after the spike, at average load for 5 minutes. Latency and errors must return to the baseline from step 2. If they do not, something is stuck: queues, connection pools, GC, an autoscaler cool-down. Gate: same as average load. Reference request: postgres indexed lookup.
Step 8 of 10. One hour of steady load. Finds leaks and slow decay in memory, connections, file descriptors, disk, log volume and cache churn. Watch the resource graphs: any line that climbs and never flattens is a finding. Gate: at most 0.5% errors. Reference request: postgres indexed lookup.
Step 9 of 10. Ramps to twenty times average over 20 minutes. Stop it when errors pass about 5%: the rate at that moment is your ceiling, and ceiling divided by peak is your capacity margin. Use a production-like environment, never production. Reference request: postgres indexed lookup.
Step 10 of 10. Average load for 15 minutes. About 5 minutes in, cause the event you are testing: kill a pod or node, fail over the database, roll out a new version, drain a zone. Errors in the window are your real availability loss. Gate: at most 1% errors overall; read the time series for how long the dip lasted. Reference request: postgres indexed lookup.
Runs four times more workers than the pool has connections, so most requests queue for a connection. Shows how the database and your pool behave when the app is slower than the traffic: latency should rise smoothly, not fall off a cliff. Reference request: postgres indexed lookup.
Frequently asked questions
What does the PostgreSQL reads load test cover?
The PostgreSQL reads template has 16 jobs: 5 single scenarios and an enterprise test plan of 11 stages (smoke, baseline, load, stress, spike, soak, breakpoint and failover window). Scenarios include postgres single-row select, postgres count(*), postgres indexed lookup and postgres two-table join. 9 of them have pass/fail targets (SLOs), so a run can be judged against limits you set.
How do I load test PostgreSQL reads with BLASTA?
Open the template in BLASTA, enter the address of your PostgreSQL reads system, then pick a job and start it. Results stream live: requests per second, latency percentiles and errors, and the run is kept in your history. To run from the command line, use blasta preset new postgres-read with your address.
Is it safe to run the PostgreSQL reads load test against production?
All 16 jobs in this template are read-only: they request pages or data and do not change anything. Even so, a load test can slow a live system down, so start with a low rate and prefer a staging copy. Only test systems you own or have permission to test.
Set up a target above and press Start test. Charts and numbers appear here as the test runs.
Load generator resources
CPU used by BLASTA % of capacity
RAM used by BLASTA
Requests per second
Latency p95 lower is better
Response time
Status codes
Errors
Pick a template
Ready-made jobs for common systems. Search by system, protocol or what you want to test
(wordpress, saml, redis, spike, login storm…), pick a job, and it opens on the Test page ready to run.
You are browsing as a visitor: you can read every template and job. Sign in or create an account to use them.
No templates match
Try a shorter search, or a system name such as keycloak, postgres or soap.