ZiRoqenl — mentorship
that follows your work
Guidance on real schemas, real constraints, and the decisions that shape how data moves through systems. Not a course — a working relationship.
What makes this kind of guidance different
Most people who come here already know SQL. They have built tables, written joins, shipped something to production. The gap is not syntax — it is judgment. Knowing when to normalize, when not to, and what the tradeoffs cost six months from now.
Sessions focus on decisions you are actually facing. A schema you are about to migrate. An indexing strategy that is not holding under load. A domain model that keeps growing in unexpected directions.
Each engagement starts with what you are working on — existing schemas, team constraints, and the decisions already made.
Recurring calls where live design problems get examined — not explained from slides, but worked through on your actual data.
Between sessions, share diagrams, migration scripts, or query plans for written feedback before you commit to a direction.
The situations people come from
There is no single profile. The common thread is a gap between what they can build and what they need to design well.
Mid-level developers stepping into architecture
They write solid application code but have never owned a schema from day one. They need to make architectural calls without a senior to defer to.
Engineers inheriting a schema they did not design
The system works but nobody fully understands it. They are responsible for extending it without making the underlying problems worse.
Solo builders who hit a wall at scale
Something that worked fine at 10k rows starts behaving strangely at 2 million. The solution is not more hardware — it is a different model.
The people behind the work
Qualifications matter less than the ability to explain a tradeoff at the right moment.
ZiRoqenl has been running mentorship engagements since 2018. The people involved have worked across PostgreSQL, MySQL, and distributed systems in production contexts — not as consultants writing reports, but as engineers who shipped and maintained the systems they designed.
Worked on schema design for multi-tenant SaaS platforms and event-sourced systems. Spent several years debugging what happens when normalization decisions from year one meet feature requirements from year four.
Focused on the gap between a schema that looks correct and one that performs correctly. Has reviewed hundreds of EXPLAIN ANALYZE outputs across PostgreSQL and MySQL environments.
The range of problems this covers
Not every engagement looks the same. Some start with a blank schema, others with a 400-table legacy system and a deadline.
Choosing the right level of normalization before a single row is written. Decisions made here compound over years.
Systems that grew organically until the structure became an obstacle. Safe migration paths without full rewrites.
Queries that worked at small scale behaving unpredictably as data grows. Index design, partial indexes, and covering indexes.
Domains where the business rules are irregular — hierarchies, versioning, polymorphic relationships, temporal data.
Choosing between shared schema, row-level separation, and separate databases — each with different isolation, cost, and operational complexity.
What people describe after working this way for a while
These are not outcome guarantees. They are patterns that come up repeatedly when people reflect on what changed in how they think about data.
Before, I would add a column and move on. Now I spend ten minutes thinking about whether I need a column at all, or whether the model is actually wrong. That shift took about three months to feel natural.
The most useful thing was having someone review a migration plan before I ran it in production. Not because I was wrong — sometimes I was, sometimes I was not — but because the review forced me to articulate my reasoning out loud.
I stopped treating indexes as a performance fix and started treating them as part of the design. That reframing changed how I read query plans entirely — they started making sense in a way they did not before.
people have worked with ZiRoqenl across engagements of 3 months or longer