Request demo
V Valk

Simulation-backed recommendations for PostgreSQL

Prove performance fixes before production.

Valk detects high-impact anomalies, explains the schema context, and validates recommended changes in isolated simulations. Built for engineers who want evidence — not guesswork.

• Metadata-only — we never touch your table data • Ephemeral sandbox simulation
Valk Findings
last 24h
SLOW_QUERY
High mean time with rising calls (delta window)
critical
fingerprint: 9f3d…a12b · table: orders · filter: user_id
UNUSED_INDEX
Zero scans over window, adds write overhead
warning
public.idx_orders_legacy_status · size: 412MB · idx_scan: 0
MISSING_INDEX
Filter/selectivity suggests a safe index candidate
info
suggested: (orders.user_id, created_at DESC) · confidence: 0.82
Simulation readiness blocked: 0
Prepared setup/test/cleanup commands for eligible findings.
Supported today
PostgreSQL-first. Read-only extraction. Simulation outputs designed for "before/after" proof.
PostgreSQL RDS / Aurora Self-hosted Kubernetes Read-only metadata

A platform built around evidence

Valk ties every recommendation to the workload signal that triggered it — and gives you a safe sandbox to validate impact before you ship changes.

Anomalies

Query-level and snapshot-level rules with deduplication, confidence scoring, and traceable evidence.

  • • Slow queries (delta windows)
  • • Missing indexes (schema-aware)
  • • Unused indexes (cross-snapshot)
Alerts

Lifecycle management: ack, snooze, resolve, verify. One issue → one alert with history.

  • • Deduplication keys
  • • Acknowledgements & suppression
  • • Verification jobs
Simulation

Isolated, ephemeral Postgres instances to validate before/after metrics with reproducible commands.

  • • Setup / test / cleanup scripts
  • • Before/after timings
  • • Risk-aware rollout guidance
Schema context

Normalized snapshots: tables, columns, indexes, constraints, triggers, routines — so recommendations stay grounded.

  • • ERD-ready representation
  • • FK + join awareness
  • • Index coverage checks

See it work before you ship it

Click "Simulate" on any anomaly and watch Valk spin up an isolated sandbox, run your query before and after the fix, and show you the proof.

1 Anomaly detected
SLOW_QUERY
SELECT * FROM orders
WHERE user_id = $1
182ms avg · 5,234 calls/day
Valk suggests: CREATE INDEX ON orders (user_id)
2 Click Simulate
Sandbox spins up...
Load schema from snapshot
Generate synthetic data
Run baseline (500 iterations)
Apply fix + run optimized
3 Before / After proof
Before
182ms
After
61ms
66.5% faster
Proof you can trust. Ship with confidence.
Playground Free-range simulation

Don't wait for anomalies. Paste any query, propose any refactor, and see the before/after instantly.

Your query
-- Paste your slow query
SELECT o.*, u.email
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 'pending'
  AND o.created_at > NOW() - '7d'
Your proposed fix
CREATE INDEX idx_orders_status_created
ON orders (status, created_at DESC)
Simulation result
Before
342ms
Seq Scan on orders
After
18ms
Index Scan
19x faster 94.7% improvement
Coming soon Fuzzy testing — Test with parameter variations, edge cases, and NULL handling

Where Valk saves you money

Slow Queries

Queries burning CPU cycles unnecessarily. Add the right index, cut execution time by 10-100x.

Typical savings: 40-80% CPU reduction
Unused Indexes

Indexes nobody uses still get updated on every write. Drop them and reclaim disk + speed up writes.

Typical savings: 5-15% write performance
Table Bloat

Dead tuples piling up? Tables growing out of control? Catch it before you need a bigger instance.

Typical savings: Avoid costly upgrades
Confidence

Stop guessing if an index will help. Simulate first, ship confidently, no rollbacks needed.

Typical savings: Hours of debugging

Your rules, your thresholds

Every team has different tolerance for query latency or index bloat. Tune Valk to match your standards — and preview changes before applying.

Fine-grained control

Set different thresholds for your most critical tables vs. background jobs. High-traffic endpoints might need tighter tolerances.

Preview before you commit

Raising your "slow query" threshold? See exactly which alerts would disappear and which would stay — before you apply the change.

Recalculate in bulk

Changed your mind on what counts as "slow"? One click recalculates all affected anomalies instantly.

Anomalies we detect
SLOW_QUERY High execution time
UNUSED_INDEX Zero scans, write overhead
VACUUM_NEEDED Dead tuple buildup
TABLE_GROWTH Rapid size increase
INDEX_TYPE_MISMATCH Wrong index type
MISSING_INDEX Filter without index
SLOW_QUERY High execution time
UNUSED_INDEX Zero scans, write overhead
VACUUM_NEEDED Dead tuple buildup
TABLE_GROWTH Rapid size increase
INDEX_TYPE_MISMATCH Wrong index type
MISSING_INDEX Filter without index
See all detection rules and configuration options →

We do NOT read your production row data

Ever. Period. Valk only accesses PostgreSQL system catalogs — schema metadata and query statistics. Your actual table data never leaves your infrastructure.

Schema metadata
Table names, column types, index definitions
Query statistics
Execution times, call counts, query fingerprints
Never accessed
SELECT * FROM your_tables — we don't need it, we don't request it
Isolation architecture
Your PostgreSQL
Production database with your data
metadata only ↓
Valk Extractor
Read-only, no table data access
Simulation Sandbox
Ephemeral, isolated, destroyed after use
no network
Your row data stays in your database. Always.
See exact permissions required →
Built with Go Rust for speed and reliability at scale

See Valk simulate your workload

Walk through your slowest queries with us. We'll show you exactly what Valk detects, how it builds simulation inputs, and the before/after proof you'd get — all in 20 minutes.

20 min walkthrough no commitment engineer-to-engineer
Get a personalized demo

Tell us about your PostgreSQL setup and we'll show you what Valk would find.

Request demo