Product Walkthrough

A day with SIXTA

A platform team manages 200+ databases for internal customers across the company. Most are self-provisioned. Developers push code daily. There's no DBA in the middle. Here's what Tuesday looks like with SIXTA on the team.

214
Database instances
18
Product teams self-serving
3
Platform DBREs
~60
Deploys per day
8:14
AM
Developer workflow
A developer on the payments team pushes a feature branch to staging. The branch includes a new reporting query against order_line_items — a 400M-row table in production. SIXTA detects the new query pattern and runs it against production-simulated load.
# payments-eng
SX
SIXTA DBRE 8:14 AM
New query detected in payments-api staging deploy by @jason.k
Query Analysis — Needs Attention
Query: SELECT order_id, SUM(amount) FROM order_line_items WHERE merchant_id = ? AND created_at BETWEEN ? AND ? GROUP BY order_id
Staging: 12ms (staging has 800K rows)
Production estimate: ~14s full table scan (production has 400M rows)
Why: No index on (merchant_id, created_at) — planner will choose seq scan at production cardinality
Fix: CREATE INDEX idx_oli_merchant_date ON order_line_items (merchant_id, created_at) INCLUDE (order_id, amount)
Expected with index: ~8ms at production scale
JK
Jason K. 8:22 AM
oh wow, didn't realize staging was that much smaller. I'll add a migration for the index before merging. Thanks SIXTA
👍 2
Without SIXTA

This query passes code review (it works fine in staging), ships to production on Thursday, and triggers a 14-second response time on the merchant reporting page at peak traffic. The on-call SRE gets paged. The payments team rolls back the deploy. The fix takes two days to re-ship with the index. Estimated cost: 4 hours of engineering time across 3 people, plus degraded merchant experience.

10:47
AM
Unmanaged database
Six weeks ago, the growth team self-provisioned a PostgreSQL instance for a new A/B testing pipeline. Nobody from the platform team has looked at it since. SIXTA has been building a baseline quietly — and today spots that autovacuum is falling behind on the main events table.
# growth-eng
SX
SIXTA DBRE 10:47 AM
Configuration assessment for growth-ab-testing-01
Health Check — 2 Recommendations
1. Autovacuum falling behind on experiment_events
Dead tuples: 4.2M (table has 28M live rows)
Last successful vacuum: 9 days ago
Risk: Transaction ID wraparound in ~3 weeks at current insert rate
Fix: Increase autovacuum_vacuum_scale_factor to 0.05, reduce autovacuum_vacuum_cost_delay to 2ms

2. Connection pool sizing
Current max_connections: 100 (default)
Peak observed: 87 concurrent
Headroom: 13% — one traffic spike from connection exhaustion
Fix: Increase to 200, or better: add PgBouncer in transaction mode
AL
Anita L. 11:03 AM
we had no idea about the vacuum thing. Applying the config changes now — can you confirm they take effect?
SX
SIXTA DBRE 11:08 AM
Confirmed — autovacuum settings active, first aggressive vacuum running now on experiment_events. Dead tuple count dropping. I'll check back in 24 hours and confirm it's caught up.
🙏 3
Without SIXTA

The growth team doesn't know what autovacuum is. Three weeks from now, the database hits transaction ID wraparound protection and goes into single-transaction mode — effectively freezing. The platform team scrambles for an emergency vacuum that takes hours on a 28M-row table. The A/B testing pipeline misses a full week of experiment data during a critical product launch.

2:15
PM
Proactive detection
SIXTA detects a slow creep in p99 query latency on one of the shared MySQL clusters used by the order management and inventory teams. It's not alerting — still within SLA — but the trend line crosses a threshold SIXTA learned from three months of baseline data.
# db-platform
SX
SIXTA DBRE 2:15 PM
Trend alert on shared-mysql-orders-01 — p99 latency rising gradually over 11 days
Diagnosis
Trend: p99 moved from 18ms → 62ms over 11 days
Root cause: inventory_snapshots table grew 34% since last month (new hourly snapshot job added by inventory team)
Impact query: SELECT * FROM inventory_snapshots WHERE sku_id = ? ORDER BY snapshot_at DESC LIMIT 1
Problem: Index on (sku_id) alone — needs snapshot_at to avoid sorting 340K rows per SKU
Fix: ALTER INDEX to (sku_id, snapshot_at DESC)
SLA risk: Will breach 100ms p99 threshold in ~6 days at current growth
MR
Maria R. 2:31 PM
Good catch — I saw the snapshot job go in but didn't think about the index implications. Go ahead.
SX
SIXTA DBRE 2:34 PM
Done — index rebuilt online, no lock contention. p99 already dropping. Will confirm it holds through tonight's peak.
👍 4
Without SIXTA

Six days from now, the order management API starts timing out during peak hours. The inventory team doesn't know their snapshot job caused it — it ran fine when the table was smaller. Maria spends half a day investigating across three dashboards before tracing it to the index. By then, two customer-facing SLA breaches have been logged.

4:40
PM
Capacity planning
The search team asked the platform team last week about whether their PostgreSQL instance can handle their planned Black Friday traffic — 3x normal query volume. The platform team forwarded the question to SIXTA.
# db-platform
SX
SIXTA DBRE 4:40 PM
Capacity assessment for search-pg-primary-01 — requested by @maria.r for Black Friday readiness
3x Load Simulation Results
Current peak QPS: 2,400
Simulated 3x peak: 7,200 QPS

Bottleneck: connection pool
Current pool: 50 connections
At 3x: Pool exhaustion at ~5,800 QPS
Fix: Scale pool to 120 + add PgBouncer

CPU headroom: sufficient
Current peak: 38% · At 3x: ~72% — within safe range

Disk I/O: 1 risk
Checkpoint completion target: Currently 0.5 (default)
At 3x: Checkpoint spikes will compete with query I/O
Fix: Set checkpoint_completion_target = 0.9 to spread writes
MR
Maria R. 4:52 PM
This would have taken me most of a day to work through. Forwarding to the search team with the connection pool and checkpoint changes as requirements for their readiness checklist.
🎯 2
6:30
PM
End of day
Maria closes her laptop. The platform team's Slack channels are quiet. SIXTA continues monitoring 214 databases — running baselines, watching for anomalies, learning query patterns from the evening batch jobs.
2:00 AM

Nothing happens.

The query that would have taken down merchant reporting was fixed at 8:22 AM. The database heading for transaction ID wraparound was tuned at 11:08 AM. The SLA breach that was six days away was resolved at 2:34 PM. The Black Friday bottleneck was identified at 4:40 PM.

The on-call engineer sleeps through the night.

4
Issues caught
0
Pages triggered
0
Incidents filed

This is what a DBRE
on every team looks like.

Three platform engineers can't review every query, tune every self-provisioned database, and plan capacity for every team. SIXTA can.

Meet Your New DBRE
Watch a full investigation from a design partner session →