TiDB Performance Sprint
When TiDB slows down and nobody can say why.
When a production TiDB workload slows down or scaling stops helping, I find the bottleneck, fix it, and measure the result — so you can serve customers reliably and decide what to scale next with evidence, not guesswork.
Find the bottleneck. Fix it. Measure the result.
Technology I build with
Marks identify technologies used; they do not imply partnership or endorsement. Postgres, PostgreSQL and the Slonik Logo are trademarks or registered trademarks of the PostgreSQL Community Association of Canada.
Recognise it?
The same job shows up a few ways.
Latency that nobody can explain
Slow queries, hotspots, uneven regions or a cluster that degrades under load, and no agreed account of why.
Capacity decided by guesswork
Is it time to scale, rebalance or change the workload — and how would you know before it hurts?
Incidents that repeat
The same class of incident returning, operational toil around the cluster, and infrastructure that drifted away from its code.
None of this is only an engineering cost. It is latency a customer notices, an incident that keeps returning before anyone is sure why, or a scaling spend committed without evidence it will fix the actual constraint.
Proof
Hands-on with TiDB and MySQL in production.
Production experience
Database Reliability Engineer at Bolt, 2022–31 October 2026. Distributed SQL reliability at scale, with Prometheus and Grafana observability. This is Andres’s employment experience, not a MoiToi customer, partner, or endorsement.
Operating depth
Production infrastructure since 1995 — Linux, databases, distributed systems, observability.
MoiToi.TECH is independent. No current or former employer is a client of this practice or endorses it, and no employer’s code, dashboards, configurations, runbooks or documents are used in it. Every tool and template is built new, from first principles and public documentation.
The engagement
TiDB Performance Sprint
What it answers
- — Which workload and which queries carry the cost?
- — Is the bottleneck the cluster, the schema or the application?
- — What would scaling actually buy?
What you get
- — workload and query analysis
- — bottleneck and resource analysis
- — evidence-based configuration, schema or application changes
- — telemetry, dashboard and alert gaps closed
- — a before/after measurement wherever one can be taken
A baseline is established before anything changes, the scope is agreed up front, and the sprint ends with a before/after measurement wherever one can be taken and a handover — not an open-ended retainer.
The first step is a 30-minute call to describe what is slow and why it matters. That conversation decides honestly whether a Performance Sprint is the right next step.
Discuss your TiDB performance problemContact
Have a TiDB performance problem?
Or write directly
connect@moitoi.tech
Andres Kepler
Product engineer and infrastructure specialist
- ee.linkedin.com/in/andres-kepler
- GitHub
- github.com/kepsic
- Practice
- MoiToi OÜ · Loksa / Tallinn, Estonia
- Web
- moitoi.tech