Oleksiy Pavlenko — Backend engineer, 6 years
Came in with a schema that worked fine at 50k records. At 4 million it became a maintenance problem. He needed someone to help him see what he could not see from inside the codebase.
Database design
that holds.
Mentorship for engineers who need their architecture decisions to survive production — not just pass code review.
Who actually shows up here
Most people who reach out are not beginners. They have shipped databases. Some have been doing it for years. The gap is usually not knowledge — it is judgment. Knowing when a denormalized table is a reasonable trade-off versus a mistake waiting to surface under load at 3am is a different skill than knowing what normalization is.
A few come from application development backgrounds where data modeling was always someone else's problem. Now it is theirs. Others are mid-level engineers who got promoted into architectural decisions before anyone explained how to reason about them. Both situations are normal. Neither is a disqualifier.
About Braktr VurdxMarta Szymańska — Lead developer, fintech startup
Her team had three different database paradigms in one product. She wanted structured thinking about when to consolidate and what the real cost of each migration path was.
Radu Florescu — Solo founder, SaaS tool
Building alone meant no senior architect to gut-check decisions. He needed a consistent second opinion without the overhead of hiring someone full-time.
What this requires from your side
01
An actual system to work on
Hypothetical schema design exercises are not what this is. You need a real project — something deployed or close to it — where decisions have consequences. Abstract discussions without context tend not to produce lasting change.
02
Tolerance for slow answers
Database design problems rarely have a single right answer. If you need quick validation more than genuine analysis, this will frustrate you. The work here involves holding multiple options in parallel before committing to one.
03
Willingness to reconsider earlier decisions
Some of what gets surfaced in mentorship will point back to decisions already made. The ability to evaluate past choices without defensiveness is genuinely necessary. It does not mean rebuilding everything — it means understanding what you built.
The main thing this addresses
The single most recurring issue is schema decisions made under time pressure that calcify into permanent constraints. A table structure chosen in week two of a project still shapes every query written in year three. Most engineers know this in principle but experience it as a surprise.
"We can't change that without rewriting everything" is the sentence that marks where the problem lives. The work here is developing the judgment to anticipate those moments before they arrive — not after you're already blocked by them.
This is not about following a specific methodology or adopting a framework. It is about training a specific type of thinking: how data structures age, where access patterns create pressure, and which trade-offs are recoverable versus which are not.
How the approach shifts with your situation
Two engineers in the same session might get structurally different responses to similar questions. That is not inconsistency — it is because the right answer depends on team size, deployment context, existing tooling, and how much technical debt is already present.
Someone running PostgreSQL with a two-person team and a strict budget has different options than someone on a managed cloud database with a dedicated DBA. The mentorship does not apply a standard template across both.
Where sessions spend time — by engineering context
When production incidents come up mid-engagement — and they do — the mentorship adjusts to address them directly. A real situation where something broke is often the clearest teaching material available. Theory lands differently when there is a specific failure to explain it against.
What this engagement actually asks of you
Regular sessions, not binge learning
The work happens in intervals — typically every one or two weeks. Gaps shorter than that often mean not enough happened between sessions to have anything useful to discuss. Longer gaps break continuity. The rhythm matters.
Work between sessions carries equal weight
What gets applied, tested, and observed in the time between sessions is where most of the actual development happens. Sessions are for analysis and direction. The gap is for doing. Both parts are required.
Months, not weeks
Architectural judgment does not form in a few conversations. Most people who see meaningful change in how they approach data modeling have been engaged for at least three months. Some patterns only become visible over a longer arc of real work.
Why this way of working holds
"You can't learn data modeling by reading about it."The approach is built around your live system, not a training exercise. Every schema reviewed, every access pattern discussed, every indexing decision examined — all of it is pulled from work you are actually doing. That specificity is where the learning sticks.
Since 2020, the consistent feedback from engineers who have gone through extended engagement is not that they learned new techniques. It is that they started catching their own mistakes earlier. That shift — from discovering problems after deployment to anticipating them during design — takes time and repeated exposure to real constraints.
There is no fixed syllabus. The sequence of topics follows what your system actually demands. If your immediate pressure is query performance, that comes first. If you are about to make a partitioning decision, that is what the next session addresses. The progression is shaped by your work, not by a preset curriculum.
The relationship continues as long as there is real work to examine. Some engineers stay for a single project cycle. Others return between projects when new architectural questions surface. Neither pattern is wrong — what matters is that the engagement has a clear purpose at each stage.