Thinking about database reliability
Technical deep-dives, industry perspective, and lessons from 25 years of database operations.
The report you wish you had when finance asks what you need next year
Every April, someone asks "what are your infrastructure needs for next year?" — and every Head of Data dreads the answer. This is a real SIXTA assessment of a production Aurora MySQL fleet. It found $109K/year in tuning savings the team didn't know they were leaving on the table, and provides the data to answer the budget question with evidence instead of guesswork.
- Current spend analysis with specific waste identified
- Six tuning fixes with dollar impact per recommendation
- Bottleneck diagnosis: what's actually limiting your throughput
- Growth readiness: what your fleet handles today vs. what you'll need
- The numbers your CFO is actually asking for, in the format they expect
Before you change anything in production, SIXTA proves it will work
SIXTA doesn't just recommend changes — it designs a safe experiment to validate them first. This sample shows a real test plan for a transaction batching optimisation: a 90-minute, fully reversible procedure with clear success criteria, expected metrics, and a rollback that takes 5 seconds. The kind of evidence you'd want before touching production at 2 PM on a Tuesday.
- Step-by-step procedure your team can execute in 90 minutes
- Before/after metrics with specific thresholds for success
- Risk analysis: what can go wrong, how to reverse it in seconds
- Three independent lines of evidence that the change worked
- Ready to present to your change advisory board or engineering lead
Sample Incident Investigation
A real-time root-cause analysis from a production incident. A database engineer asked SIXTA to investigate a 15-minute anomaly window — SIXTA identified three distinct events, traced them to a batch job via connection pool and handler statistics, and provided four prioritised recommendations.
- Full root-cause analysis completed in under 10 minutes
- Evidence chain: connection pool signature, chunked processing pattern, table scan detection
- Downstream effects analysis: lock contention, slow log failure, disk alert
- Follow-up investigation correcting a misleading disk usage alert
- Four actionable recommendations with supporting evidence
Security Architecture Pack
A condensed 5-page PDF summarising SIXTA's data flow, permissions model, network posture, autonomous action guardrails, and audit logging approach. Designed for security reviewers to attach to internal vendor evaluations.
Download PDF — No email requiredWhat is a DBRE? The Database Reliability Engineering Role Explained
The DBRE role was coined in 2017 and applies SRE principles to database operations. How DBREs differ from DBAs, what they do day to day, and why the role is growing as database estates scale beyond what any single team can manage manually.
Read article →How to Reduce Database MTTR: A Practical Guide
The average database incident takes 3 to 5 hours to resolve. Best-in-class teams do it in under 60 minutes. A practical framework covering the seven most common failure modes and five techniques that compress resolution time.
Read article →PostgreSQL Performance Tuning Beyond the Defaults
PostgreSQL ships with defaults designed for compatibility, not performance. A practical guide to vacuum tuning, query analysis with pg_stat_statements, and why manual parameter tuning has a ceiling that ML-driven approaches are beginning to raise.
Read article →MySQL Performance at Scale: Bottlenecks, Diagnostics, and What Comes Next
Aurora's 5x claim, Performance Schema diagnostics, pt-query-digest, the Vitess sharding ecosystem, and the emerging VillageSQL extension framework. A practical guide to MySQL performance analysis using USE and RED methodology.
Read article →The Real Cost of Database Incidents
A single hour of database downtime costs over $300,000 for 90% of mid-size enterprises. But direct cost is only the beginning. Engineer burnout, customer churn, compliance exposure, and development velocity loss compound for months.
Read article →Database Observability vs Monitoring: Why Dashboards Aren't Enough
Monitoring tells you when known thresholds are breached. Observability lets you ask questions you didn't know you'd need to ask. The distinction matters: organisations without full-stack observability face outage costs at twice the rate of those with it.
Read article →PostgreSQL isn't winning because it's better
PostgreSQL is becoming the default not through technical superiority, but through developer toolchains like Supabase and Lovable. The same pattern that made MySQL dominant in the 2000s is now playing out in reverse.
Read article →Even if MySQL became the default again, it would still lose
PostgreSQL has two structural advantages MySQL can't easily replicate: its extension ecosystem and the community model that drives it. Why the window for a MySQL comeback may already have closed.
Read article →Calling AI code slop is lazy
The backlash against AI-generated code mirrors the backlash against Rails in the late 2000s. GitHub, Shopify, and Airbnb all launched on the "toy framework." The pattern is the same: new tools lower the bar, incumbents panic, and the ceiling rises anyway.
Read article →The AI hype is colliding with reality
MIT found that 95% of enterprise AI pilots deliver no measurable P&L impact. The 5% that work share a pattern: specificity beats generality, native beats bolted-on, and workflow integration beats feature lists.
Read article →Ask not what AI can do for you
Treating AI as a teammate rather than just a tool changes the way you build with it. Thoughts on collaboration over delegation, and what it means for operations teams.
Read on LinkedIn →Where does your war room actually live?
58% of teams coordinate database incidents in Slack or Teams, not a physical room. The shift to chat-based triage changes what incident tooling needs to look like, and what skills your on-call engineers actually need.
Read article →Observability and the Art of Managing Our Ignorance
We can't monitor what we don't know to look for. A long-form piece on why observability needs to move beyond dashboards toward systems that surface what you didn't think to ask.
Read on LinkedIn →AI isn't a bubble. It's a correction.
The current AI investment cycle looks different from previous tech bubbles. A look at why the infrastructure layer is where the real value compounds — and what that means for operations.
Read on LinkedIn →Why do we still trust metrics that lie to us?
Teams celebrate 99% cache hit ratios while their databases burn. The metric looks perfect, but the queries are reading 50x more data than needed. A problem first described in 2004 that we still haven't solved.
Read on LinkedIn →The gap between troubleshooting data and strategic intelligence
As database estates grow more complex, teams cobble together CloudWatch, observability tools, and CUR data — generating data without increasing visibility. Why the next layer of database intelligence needs to work differently.
Read on LinkedIn →You can't jump from manual database ops to full AI autonomy
The trust problem in database automation isn't technical — it's human. A response to Percona's vision for the future of database management, and why progressive trust matters more than raw capability.
Read on LinkedIn →SIXTA has a CTO: Andrew Morgan
Andrew joins from Capital One and VividCortex, bringing six years of database monitoring experience. His path from Computer Science to Government to product management gives SIXTA an unusual perspective on building for operators.
Read on LinkedIn →Andy Ellicott joins as advisor
Andy brings a decade of database and open source go-to-market experience from Vertica, Cloudant, IBM, Starburst Data, and DBOS. At this stage, positioning matters more than product — and Andy knows why database companies win and lose.
Read on LinkedIn →Christian Bilien joins as advisor
Christian spent 25 years leading database infrastructure at SocGen and BNP Paribas — environments where a database incident is a regulatory event. His experience shapes how SIXTA thinks about compliance, trust, and enterprise requirements.
Read on LinkedIn →The reactions when I demo SIXTA keep blowing me away
Feedback from early demos — monitoring vendors, VP-level executives, and database engineers. What resonates: the speed of root cause analysis, the financial granularity, and the fact that it was built in months, not years.
Read on LinkedIn →Follow Ewen for weekly takes on database reliability, AI in operations, and building SIXTA.
Follow on LinkedIn →Want to see this on your own data?
SIXTA produces these analyses continuously across your database fleet. Book a call and we'll show you what it finds in your environment.
Meet Your New DBRE