Database Administration
Long-term mentorship for database professionals who want depth, not shortcuts
Adjusting to where you actually are
The method shifts depending on whether you're firefighting daily or planning for scale.Most programs hand you a syllabus and expect you to fit it. Work here moves the other way — sessions start from what you ran into this week, what query caused the slowdown, what schema decision felt wrong but you shipped anyway. That specificity is the point.
Whether you're managing a single PostgreSQL instance or inheriting a legacy Oracle setup that nobody documented, the approach changes accordingly. Some weeks that means dissecting execution plans together. Others it means talking through indexing strategy at a whiteboard level before touching anything.
The core problem
Knowing SQL is not the same as understanding your database under load
The gap that shows up most consistently isn't syntax — it's reading what the database is actually doing. An EXPLAIN ANALYZE output, a wait event histogram, a bloat report from pg_stat_user_tables — these tell you what's wrong, but only if you know how to read them. Most people learn that skill slowly, under pressure, after something breaks.
Debugging a slow query at 2am with production breathing down your neck is not the best time to be learning about sequential scans versus index scans.
The mentorship addresses this specifically — not by handing you a checklist, but by working through your actual query plans and wait statistics until that kind of reading becomes instinctive. It takes time. It's also one of the few things that genuinely reduces the number of incidents you'll face later.
- Slow queries with no clear cause in application code
- Replication lag that appears only under write spikes
- Maintenance windows that run longer than planned
- Autovacuum behavior that no one on the team fully understands
What's different after several months of structured work
The change isn't dramatic or sudden — it accumulates. After consistent work together, the pattern that shows up most clearly is a shift in confidence when something unexpected happens in production. Not overconfidence — more like knowing which direction to look first.
People stop reaching for the same three EXPLAIN flags every time and start reading the broader picture: connection saturation, lock chains, vacuum lag across tables. The decisions they make are better documented because they understand why, not just what to do. That understanding travels with them regardless of which database they end up working with next.
"Structured guidance on reading a slow query log is the kind of thing that used to take two or three failed incidents to learn on your own."
Faster incident response
Diagnosing a performance drop moves from hours of guessing to a more structured 20-30 minute investigation with clear findings.
Documented reasoning
Schema decisions and tuning choices come with written rationale, so future team members aren't inheriting a mystery.
Backup confidence
Recovery procedures get tested, not just written. Knowing your RTO is achievable makes maintenance less stressful for everyone.
Proactive maintenance habits
Vacuum schedules, index bloat checks, and replication health reviews become routine — not things that happen only after a problem.
"I used to avoid touching autovacuum settings because I wasn't sure what would break. After working through it with someone who could explain the mechanics, I actually understand what the settings do."
— Radek Ošlejšek, database administrator, mid-size logistics company. Working with Hesbo Jundal since 2022.
hesbojundal.com