DEV Community

Cover image for pg-stress — Stress Testing PostgreSQL with Claude-powered advisory
Burnside Project
Burnside Project

Posted on

pg-stress — Stress Testing PostgreSQL with Claude-powered advisory

Test it like It’s a Machine

When I started building pg-collector (another project that uses heavy stress test using pg-test), I ran into a problem very quickly:

I didn’t have a reliable way to break PostgreSQL on demand. I looked and there are lots of generating synthetic data but no comprehensive stress test tools.

And that’s when the idea for pg-stress was born.

Built from “eat your own dog food”

pg-stress didn’t start as a product idea.
It started as a necessity.

While building pg-collector, I needed:
• real workload patterns
• repeatable failure scenarios
• controlled environments to observe behavior
• run these test in random pattern continously 7/24 for 2 weeks !

So I built a tool to stress PostgreSQL intentionally — not just benchmark it.

That tool became pg-stress.

Think of it like automobile testing

When a new car is built, it’s not just driven on smooth roads.

It’s tested in:
• freezing cold
• extreme heat
• rough terrain
• high-speed stress conditions

Why?

Before releasing a new query in the **WILD - inject that query in pg-stress. Stress test with 100s of connections, test the joints, insert 10M rows(kidding ! Not really .. I inserted 30M records …)Output the findings to Claude Chat box for advisory!

Databases are no different.

Production issues show up under:
• traffic spikes
• bad queries
• ORM inefficiencies
• long-running transactions
• unpredictable write patterns

pg-stress is built to simulate exactly that.

What pg-stress actually tests

This is not just “run SELECT 1 in a loop.”

We push real-world chaos into PostgreSQL:

ORM-like behavior

• bursty inserts / updates / deletes
• inefficient query patterns
• transactional noise
Enter fullscreen mode Exit fullscreen mode

Jitter + randomness

• non-uniform traffic
• unpredictable workloads
• concurrency spikes
Enter fullscreen mode Exit fullscreen mode

Bloat & connection pressure

• table/index bloat scenarios
• connection exhaustion
• lock contention
Enter fullscreen mode Exit fullscreen mode

Query stress

• slow queries under load
• joins at scale
• degradation over time
Enter fullscreen mode Exit fullscreen mode

From stress → context → intelligence

Most stress tools stop here:

“Here are your TPS and latency numbers.”

That’s not enough.

pg-stress produces structured output designed for context:
• query behavior
• system response
• degradation patterns

Built for AI-assisted diagnosis

The output of pg-stress is optimized for modern workflows:

Feed it directly into models like Claude

And you can get:
• query tuning recommendations
• index suggestions
• capacity predictions
• failure explanations

Part of a bigger system
• pg-stress → generates pressure
• pg-collector → observes + learns
• (future) → AI layer predicts and advises

Final thought

If you can’t break your database in a controlled environment…

It will break in production — on its own terms.

Repo:

DataEngineering

AIInfrastructure

MachineLearning

PostgreSQL

OpenSource

Top comments (0)