Open-Source Testing · lesovsky

noisia

Noisia is a specialized PostgreSQL workload generator written in Go that deliberately creates harmful database conditions (idle transactions, deadlocks, WAL flooding, replication slot bloat) to test system resilience and failure recovery. It is explicitly designed for testing and chaos engineering, not production use, and includes detailed documentation on workload impact and remediation strategies.

Talk to DEV.co Discuss Implementation

Source: GitHub — github.com/lesovsky/noisia

716

GitHub stars

Forks

Primary language

BSD-3-Clause

License (OSI-approved)

Key facts

Objective fields from the source. Values we can't verify are shown as “Unknown” rather than guessed.

Field	Value
Repository	lesovsky/noisia
Owner	lesovsky
Primary language	Go
License	BSD-3-Clause — OSI-approved
Stars	716
Forks	19
Open issues	0
Latest release	v0.3.0 (2026-06-29)
Last updated	2026-07-07
Source	https://github.com/lesovsky/noisia

What noisia is

Noisia injects multiple classes of PostgreSQL pathologies—connection exhaustion, transaction blocking, memory leaks via prepared statements, temporary file spillover, replication slot pinning, and WAL flood—via parallel worker processes. The tool is importable as a Go library and provides granular configuration for tuning workload intensity, timing, and connection parameters.

Quickstart

Get the noisia source

Clone the repository and explore it locally.

terminalbash

1git clone https://github.com/lesovsky/noisia.git2cd noisia3# follow the project's README for install & configuration

Need it deployed, integrated, or customized instead? DEV.co ships production installs.

Best use cases

PostgreSQL Failure-Injection Testing

Generate controlled chaos (deadlocks, slot bloat, WAL flood) in staging/test environments to validate alerting, auto-remediation, and incident response procedures before production outages occur.

Capacity and Tuning Validation

Stress-test autovacuum settings, connection pooling limits, work_mem, and replication lag tolerance by injecting known pathologies and measuring recovery time and resource overhead.

Chaos Engineering & Resilience Drills

Simulate realistic PostgreSQL failure modes (backend OOM, replication lag, disk fill) to practice incident triage, measure MTTR, and validate monitoring and alerting thresholds.

Implementation considerations

Run only in isolated, non-production staging environments with dedicated compute and storage; never share infrastructure with production or live services.
Configure strict timeouts and context cancellation to prevent runaway workload execution; use Docker with resource limits (memory, CPU) to cap blast radius.
Instrument PostgreSQL with real-time metrics (pg_stat_* views, WAL disk usage, replication lag) and set up immediate alerting/kill-switch automation before starting any workload.
Document baseline performance (query latency, connection pool saturation, disk I/O) before each test run to quantify the workload's impact and validate remediation steps.
Review the built-in demo and tuning guides for each workload; each has specific recovery procedures (VACUUM FULL, pg_repack, slot reset) that must be validated offline first.

When to avoid it — and what to weigh

Production Database Exposure — The tool is explicitly not safe for production; even brief, misconfigured runs risk OOM-kill, instance restart, WAL disk fill, or transaction blocking that cascades to dependent systems.
Inadequate Monitoring/Isolation — Without isolated staging infrastructure, real-time PostgreSQL metrics, and ability to kill the tool quickly, workload impact can spiral into uncontrolled failure (e.g., slot-bloat filling the disk).
Safety-Critical or Always-On Workloads — Any database or application tier requiring zero-downtime or guaranteed availability during testing cannot tolerate noisia's deliberate service degradation and connection termination.
Unfamiliar PostgreSQL Internals — Without understanding WAL, replication slots, HOT updates, autovacuum, and backend memory lifecycle, operators risk misinterpreting results or failing to recover from workload-induced states.

License & commercial use

BSD-3-Clause (BSD 3-Clause 'New' or 'Revised' License) is a permissive OSI-approved license that permits commercial use, modification, and distribution with minimal restrictions (retain copyright/license notice, no liability).

BSD-3-Clause permits use of noisia in commercial testing, CI/CD, and chaos engineering pipelines without license restriction. No commercial license needed. However, ensure your use case is strictly non-production testing; any production deployment or reliance on the tool for critical systems voids the disclaimer and may incur liability under your organization's own terms.

DEV.co evaluation signals

Editorial assessment — not user reviews. Directional, with an explicit confidence level.

Signal	Assessment
Maintenance	Active
Documentation	Strong
License clarity	Clear
Deployment complexity	Moderate
DEV.co fit	Good
Assessment confidence	High

Security considerations

Noisia is a controlled chaos tool, not a security scanner or vulnerability finder. No authentication bypass or encryption features are described. Primary risk is operational: misconfiguration or uncontrolled execution can cause data loss, service outages, or unintended downtime. Ensure noisia is run only by authorized personnel in isolated environments with strict IAM controls on database credentials and test infrastructure access.

Alternatives to consider

pgbench (PostgreSQL built-in)

Benchmarks read/write throughput and latency; does not inject pathologies like deadlocks, slot bloat, or backend OOM. Simpler but lacks failure-mode testing.

Chaos Monkey / Gremlin

General-purpose chaos engineering platforms for infrastructure (CPU, network, disk) but do not provide PostgreSQL-specific workloads (replication slot pinning, autovacuum race conditions, temporary file spillover).

pg_chaosmonkey (custom scripts/tools)

Ad-hoc or custom PostgreSQL chaos tooling; less polished and requires in-house maintenance but may offer greater control over specific workload patterns.

Software development agency

Build on noisia with DEV.co software developers

If you're building a robust PostgreSQL deployment and need to validate failure recovery, alerting, and incident response, Noisia provides the chaos injection tools. Start in a staging environment and review the workload tuning guides before your first run.

Talk to DEV.co

Related open-source tools

Surfaced by semantic similarity across the DEV.co open-source index.

NoSQLMap database-lab-engine pgmodeler

Related on DEV.co

Explore the category and the services that help you build with it.

Open-Source Testing DevOps & Infrastructure Testing Custom Software & Test Harnesses Talk to DEV.co

noisia FAQ

Can I run noisia against my production database?

No. The tool explicitly disclaims production use and will cause service degradation, data corruption risk, or instance restart. Use only in isolated staging/test environments.

How do I recover from a workload-induced state (e.g., full pg_wal disk)?

Each workload has a dedicated tuning guide with recovery steps (e.g., slot reset for slot-bloat, VACUUM FULL for bloat-churn). Review these before running the workload; recovery must be tested offline first.

What PostgreSQL versions does noisia support?

Not explicitly stated in the provided data. Requires review of the repository or release notes.

Can I use noisia in my CI/CD pipeline?

Yes, if integrated into isolated test stages with dedicated PostgreSQL instances, real-time metrics, timeouts, and automated cleanup. Docker and Go library support facilitate integration. Ensure tests do not share infrastructure with production or staging services.

Custom software development services

Need help beyond evaluating noisia? DEV.co is a software development agency offering software development services and web development for teams of every size. Our software developers and web developers build custom software, web applications, APIs, and open-source testing integrations — and maintain them long-term.

Ready to Test PostgreSQL Resilience?

Talk to DEV.co Schedule a Consultation