Redline

A lightweight, real-time database performance monitor that provides instant visibility into query execution patterns and bottlenecks.

Why This Exists

Most database monitoring tools are either too heavy (full APM suites) or too manual (running EXPLAIN repeatedly in psql). Redline sits in the middle: a single binary that connects to your database and streams performance insights in real-time.

Built to understand how production databases actually fail under load.

Architecture

┌─────────────┐
│  PostgreSQL │
│             │
│ pg_stat_*   │
└──────┬──────┘
       │ read-only
       ▼
┌─────────────┐
│  db-monitor │ ←─ polls every 1-2s
│  (Go)       │    computes deltas
│             │    detects regressions
└──────┬──────┘
       │ WebSocket
       ▼
┌─────────────┐
│   Web UI    │ ←─ live updates
│  (React)    │    query details
│             │    EXPLAIN plans
└─────────────┘

Key Design Principles:

• Zero schema changes (only requires pg_stat_statements extension)
• Read-only connections
• Stream interpreted events, not raw data
• In-memory state with optional persistence
• Single binary deployment

Features

• Real-time Query Monitoring - See execution time, call frequency, and trends as they happen
• Intelligent Alerting - Automatic detection of performance regressions and anomalies
• On-Demand Query Plans - Click any query to see its EXPLAIN plan with highlighted bottlenecks
• Delta Analysis - Track changes in query performance over rolling time windows
• Query Normalization - Automatic grouping of parameterized queries

Quick Start

Fastest way:

docker compose up

Open http://localhost:3000 to see live monitoring.

Detailed setup: See QUICKSTART.md

Configuration

Environment variables:

DB_HOST=localhost
DB_PORT=5432
DB_USER=readonly
DB_NAME=postgres
DB_SSLMODE=disable
POLL_INTERVAL=2s
WS_PORT=8081

What Gets Monitored

Metric	Source	Purpose
Query text	pg_stat_statements	Identity & normalization
Execution time	total_exec_time / calls	Performance baseline
Call frequency	calls delta	Load patterns
Active queries	pg_stat_activity	Current state
Wait events	pg_stat_activity	Contention diagnosis

Project Structure

.
├── cmd/
│   └── db-monitor/       # Main entry point
├── internal/
│   ├── collector/        # Polling & delta computation
│   ├── db/              # Database queries
│   ├── models/          # Core types
│   ├── server/          # HTTP & WebSocket server
│   └── ws/              # WebSocket hub
├── web/                 # React frontend
├── docker/              # Docker setup
└── docker-compose.yml   # One-command demo

Known Limitations

• PostgreSQL only (MySQL support planned)
• No authentication (not production-ready as-is)
• In-memory only (no historical persistence beyond rolling windows)
• Single database (no multi-tenant support)

What I'd Build Next

Given more time, the natural extensions would be:

1. Alert Rules - Configurable thresholds with webhooks
2. Index Recommendations - Analyze query patterns to suggest missing indexes
3. Query Comparison - Diff EXPLAIN plans before/after changes
4. Multi-Database - Monitor multiple instances from one UI
5. Historical Storage - Optional persistence layer for long-term analysis

Technical Deep Dive

Delta Computation

Redline doesn't just show current stats—it computes deltas between poll intervals:

delta := current.TotalExecTime - previous.TotalExecTime
callDelta := current.Calls - previous.Calls
meanLatency := delta / float64(callDelta)

This enables:

• Trend detection (is this query getting slower?)
• Anomaly detection (sudden spike in calls?)
• Rate calculations (queries/second, latency changes)

Query Normalization

Uses PostgreSQL's built-in queryid when available, with fallback normalization:

• Strip literal values (WHERE id = 123 → WHERE id = ?)
• Normalize whitespace
• Preserve query structure for meaningful grouping

EXPLAIN Plan Analysis

When you click a query:

1. Frontend requests explanation for queryid
2. Go service looks up normalized query text
3. Executes EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
4. Parses plan tree to extract:
   • Sequential vs index scans
   • Rows filtered vs returned
   • Buffer hits/misses
   • Actual execution time per node

License

MIT

---

Note: This is a monitoring tool, not a replacement for proper database administration. Always test in non-production environments first.