Hesbo Jundal — Database Mentorship

Behind every stable database is someone who knew what to look for

We work with administrators who want to stop guessing and start managing databases with actual confidence — through sustained, one-on-one guidance built around their specific environment.

Database administration workspace at Hesbo Jundal Est. 2019 · Donetsk, Ukraine

What shaped this practice

Hesbo Jundal started from a specific frustration: most database training stops at theory. You learn SQL syntax, maybe some index concepts — then you're handed a production system and left to figure out the rest. We built the mentorship model we wished existed when starting out.

Each mentorship engagement runs for a minimum of three months, with structured weekly sessions and a direct line for questions between them.

The focus is on PostgreSQL, MySQL, and MSSQL environments — the systems that actually run most businesses. Sessions cover real situations: slow queries, replication lag, backup verification gaps, storage planning, and the kind of maintenance decisions that only look obvious after someone walks you through them once.

Database maintenance session in progress
6 avg. months before first mentorship
12 avg. weeks to independent confidence

The people you'll actually work with

No rotating roster — you work with one mentor consistently across the entire engagement.

Oleksiy Vrazhko, Lead Database Mentor

Oleksiy Vrazhko

Lead Database Mentor

Oleksiy spent nine years managing production databases for logistics and fintech companies before moving into full-time mentorship. His approach to query optimization is methodical — he reads execution plans the way others read error logs, tracing problems backward from symptom to cause.

PostgreSQL Query tuning Replication Backup strategy
Daryna Khomych, Database Systems Specialist

Daryna Khomych

Database Systems Specialist

Daryna's background is in database architecture for mid-sized SaaS products, where capacity planning and schema design decisions had immediate business consequences. She works with clients on longer-horizon thinking — not just fixing what's broken today but avoiding what breaks next quarter.

MSSQL Schema design MySQL Capacity planning

Mentorship intensity scale — current availability

Open Limited Full

How sessions actually run

Every client starts with a two-hour intake where we look at the actual environment — schema, query logs, current backup setup, anything that gives us a realistic picture. From there, sessions are structured but not scripted. They follow what's happening in the client's database, not a fixed curriculum.

Database review session documentation
  • Continuity over sessions

    Notes from every session are shared the same day. We track open questions across weeks so nothing gets dropped between calls, and decisions made in month one inform the work in month three.

  • Specific environments, not generic advice

    There's a real difference between tuning a 40 GB OLTP database and an 800 GB analytical store. We don't give standard answers — we look at what you're actually running and work from there.

  • Decisions you can defend

    Part of the work is building the reasoning behind choices — not just knowing that a partial index is faster in this case, but understanding why, so you can apply the same thinking to the next situation without needing to ask again.

  • Scope limited by design

    We work with a small number of clients simultaneously. Mentorship that's spread too thin becomes just email responses and shared articles. The cap exists to keep every engagement substantive.