FaultWall – Which tenant is killing your Postgres? Now you can find out

Name: FaultWall – Which tenant is killing your Postgres? Now you can find out
Availability: InStock
Author: shreyssh

by shreyssh·Mar 27, 2026·2 points·0 comments

Visit Project View on HN

AI Analysis

●●SolidSolve My ProblemBig Brain

Auto-throttles noisy Postgres tenants using pg_terminate_backend before Datadog even alerts you.

Strengths

•Auto-detects tenant isolation pattern (schema, row-level, database) without configuration
•Cost attribution shows exactly which tenant drives 94% of your RDS bill
•MCP server enables LLM agents to query health and throttle without human intervention

Weaknesses

•PostgreSQL only—no MySQL or managed database support mentioned
•Competes with established DB observability tools like Datadog and pganalyze

Post Description

Slow database pages kept waking me up. Every time, same story: dig through pg_stat_activity, find a runaway query, trace it back to one tenant doing something dumb, kill the connection, go back to sleep. Next week, different tenant, same thing.

Datadog never told me the tenant. So I built FaultWall.

Single Go binary, polls pg_stat_statements every 10s, maps queries to tenants via schema detection. Gives you per-tenant QPS, P50/P95/P99 latencies, cost attribution ("acme_corp is 94% of your DB bill"), and an auto-throttler that pg_terminate_backend() before things get bad.

Anomaly detection with self-tuning thresholds (genetic algorithm). MCP server for LLM agent control. I'm building eBPF kernel-level per-query tracing, for better and accurate detection.

DATABASE_URL=postgres://... ./faultwall

If you run multi-tenant Postgres, try it and tell me what's missing.

MIT, ~2500 lines Go. https://github.com/shreyasXV/faultwall