Private corporate batches, live online cohorts and 1-on-1 mentoring in horizontal sharding for MySQL — vtgate routing, VSchema vindexes, VReplication resharding and online DDL — taught by a practitioner who runs it in production.
20 years across DevOps, SRE and Security · 10,000+ engineers trained · Trained teams at JPMorgan Chase, Verizon, Nokia and the World Bank
Principal DevOps Engineer & Architect
Rajesh teaches Vitess around the two decisions that determine whether a deployment succeeds — the sharding key and the cutover. Sessions cover VSchema and vindex design from the query pattern backwards, including lookup vindexes and sequences, and the query-serving limits that follow: what routes to one shard, what scatters, what cannot be planned at all, and how transaction modes behave across shards. The operational half is run live: MoveTables to migrate into Vitess, Reshard to split shards under load, VDiff to verify before cutover, SwitchTraffic and its reverse, planned and emergency reparenting, backups and point-in-time recovery, and managed online DDL with the replication-lag throttler — demonstrated against a running cluster rather than described on slides.
Twenty years across DevOps, SRE and Security, in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe and others. He has trained engineers at JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus — more than 10,000 people personally. He teaches what he runs, not what he reads.
You are booked with a named engineer, and that is who turns up. Marketplaces and larger providers rotate whoever is free, so the person who sold you the agenda is rarely the person teaching it.
The same trainer is available for the next engagement, which matters when a team builds on what it learned last time.
Your batch is assigned a named trainer before it starts, and that is who teaches it. See the full faculty.
Engagements are matched on the tool, not the calendar. For Vitess that means a trainer who has run it in production — horizontal sharding for MySQL — vtgate routing, VSchema vindexes, VReplication resharding and online DDL — rather than whoever is free that week. You are told who is teaching before you commit, and that person is on the discovery call that shapes the agenda.
Where a batch is large enough to need a second trainer, the pairing is declared up front. The lead trainer stays accountable for the syllabus and the assessment either way.
Principal DevOps Engineer & Architect
Twenty years across DevOps, SRE and Security in principal and architect roles at PayPay, SoftwareAG, ServiceNow, JDA Software, Intuit, Adobe, IBM/Emptoris, Ness, MindTree and Accenture. He has trained more than 10,000 engineers personally, at organisations including JPMorgan Chase, Verizon, Nokia, the World Bank, VMware, Oracle, Mercedes-Benz and Airbus. He teaches what he runs, not what he reads.
Teams of 8–30
Custom agenda, your timezone, onsite or online, NDA-friendly.
Request a quoteIndividual engineers
A private instructor and a curriculum built around your goal.
₹99,999Individuals who want peers
Scheduled batch, max 8 to 10 hours of live instruction.
₹34,999A private batch starts with a discovery call. We look at the stack you actually run — the CI system, the cloud, the constraints — and map the agenda onto it, so examples use your topology rather than a generic one.
Delivery is onsite at your premises, live online, or hybrid, scheduled around your release calendar rather than ours. Batches run 8 to 30 engineers.
Every attendee leaves with recordings, slides, lab repositories and a completion certificate. You receive an attendance and assessment report. Invoicing supports PO and GST.
Talk to us about a private Vitess batchVitess is a database clustering system that gives MySQL horizontal scale without asking applications to learn a new database. It sits in front of a fleet of MySQL instances and speaks the MySQL wire protocol, so an existing client connects to Vitess exactly as it would to a single server. Behind that connection, vtgate parses each query, consults a sharding schema and routes it to the right shard — or scatters it across many and gathers the results. Vitess graduated from the CNCF and originated at YouTube, where it was built to keep a single logical database serving traffic that no single instance could hold.
The architecture has three moving parts. vtgate is the stateless proxy that plans and routes queries. vttablet runs beside each MySQL instance and does the work that protects it: connection pooling so thousands of client connections become tens of MySQL connections, query rewriting and row-count limits, transaction pooling, query consolidation for duplicate in-flight reads, and hot-row protection. A topology service — etcd, ZooKeeper or Consul — holds the cluster's shape: keyspaces, shards, tablet records and the VSchema. That VSchema is where sharding is actually defined, through vindexes that map a column value to a keyspace ID and therefore to a shard, including lookup vindexes for querying by a column that is not the sharding key.
The operational half is VReplication, the engine underneath the workflows teams actually run. MoveTables migrates tables into Vitess or between keyspaces with traffic still flowing; Reshard splits or merges shards; VDiff verifies that source and target match before cutover; SwitchTraffic moves reads and writes and can be reversed. Around those sit durability policies with semi-synchronous replication, planned and emergency reparenting, VTOrc for automated failover, backups, managed online schema changes with a lag-aware throttler, and a Kubernetes operator.
MySQL remains the default relational engine for a large share of the industry, and the scaling wall it hits has not moved: one primary accepting writes, a dataset that no longer fits comfortably, and a maintenance window that keeps getting harder to schedule. The usual responses — read replicas, a bigger instance, or application-level sharding written by hand — each run out. Application-level sharding in particular tends to become the most expensive code in the company, because every join, every schema change and every rebalance becomes bespoke.
Vitess is the mature open-source answer to that. It is CNCF-graduated, runs at very large scale in public deployments, and underpins commercial MySQL platforms — which means the skill is portable across self-hosted and managed environments. Teams reach for it when the write path is saturated, when connection counts are crushing MySQL, or when zero-downtime schema change and shard splits need to be routine rather than heroic.
The demand is specifically for operational depth. Bringing up a Vitess cluster is a day's work; choosing a sharding key that does not force every query to scatter, running a reshard on live traffic with VDiff verification and a reversible cutover, and reasoning about transaction semantics across shards are what organisations actually hire for.
The scaling problem stated properly before the tool is introduced. Where read replicas help and where they do not, why write scale and connection count are separate problems, what application-level sharding really costs, and how Vitess compares to ProxySQL, Aurora and managed sharded platforms.
Topics: MySQL scaling limits: writes, dataset size, connections, schema change · Read replicas, vertical scaling and their ceilings · Application-level sharding and its long-term cost · Vitess compared with ProxySQL, Aurora and managed alternatives · What Vitess does not solve · Vitess history, CNCF status and where it runs today · Component overview and the shape of a cluster
Standing up Vitess and understanding each component while doing it. vtgate as the stateless query planner, vttablet as the guardian in front of each MySQL, vtctld and vtctldclient as the control plane, and the topology service that holds the cluster's shape.
Topics: vtgate: query planning, routing and the MySQL protocol endpoint · vttablet: connection pooling, query rewriting, row limits, consolidation · Tablet types: primary, replica, rdonly, and their roles · vtctld, vtctldclient and the administrative surface · Topology service with etcd, ZooKeeper or Consul · Keyspaces, shards and shard naming · Bringing up an unsharded keyspace and connecting a client · vtexplain and reading a query plan
The decision the whole deployment rests on. How a keyspace ID is computed, what a vindex is and which one to use, secondary and lookup vindexes for querying by non-sharding columns, sequences to replace AUTO_INCREMENT, and how to derive a sharding key from actual query patterns rather than intuition.
Topics: Keyspace IDs, key ranges and shard boundaries · Primary vindexes: hash, xxhash, binary, numeric · Functional versus lookup vindexes · Unique and non-unique lookup vindexes, and consistent lookup · Sequences and distributed identifier generation · Modelling related tables to keep joins on one shard · Choosing a sharding key from query patterns and access frequency · Multi-tenant sharding patterns · The cost of getting the shard key wrong
What Vitess can and cannot do with SQL, stated plainly. Single-shard routing against scatter-gather, cross-shard joins and aggregation, unsupported constructs, OLTP and OLAP modes, and the transaction modes — including why two-phase commit across shards is rarely the right answer.
Topics: Routing: single-shard, multi-shard and scatter queries · Cross-shard joins, aggregation and sorting · Constructs Vitess cannot plan, and how to rewrite them · OLTP versus OLAP workload modes · Transaction modes: single, multi and twopc, with their trade-offs · Cross-shard transaction semantics and atomicity guarantees · Connection and transaction pooling in vttablet · Query consolidation and hot-row protection · Query rules, blocklists and row-count limits · Reading vtgate and vttablet query statistics
The engine that makes live migration possible. How VReplication streams changes from source to target, MoveTables for bringing an existing database into Vitess or moving tables between keyspaces, VDiff for proving the copy is correct, and SwitchTraffic with a reverse path that makes cutover safe.
Topics: VReplication concepts: streams, filters, positions · MoveTables workflow lifecycle · Vertical splits: separating tables into their own keyspace · Copy phase, catch-up and replication lag during migration · VDiff and VDiff2 for row-level verification · SwitchTraffic for reads and for writes, separately · ReverseTraffic and aborting a cutover safely · Cleaning up completed workflows · Migration from an external MySQL into Vitess
The operation Vitess exists to make routine. Splitting a shard into two, merging shards back, running the workflow while the application keeps writing, verifying with VDiff, switching read and write traffic in stages, and monitoring what the application experiences throughout.
Topics: Reshard workflow: source shards, target shards, key ranges · Splitting one shard into two, and further splits · Merging shards and shrinking a keyspace · Monitoring copy progress and replication lag · VDiff verification before switching · Staged traffic switching: rdonly, replica, then primary · The write cutover window and what clients see · Reversing a reshard · Post-reshard cleanup and vindex implications · Capacity planning for shard count
Keeping the data safe and the shard available. Replication topology and durability policies, semi-synchronous replication, planned reparenting for maintenance and emergency reparenting for failure, VTOrc for automation, and a backup and restore practice that is actually rehearsed.
Topics: MySQL replication under Vitess and tablet health · Durability policies and semi-synchronous replication · PlannedReparentShard for maintenance · EmergencyReparentShard after a primary failure · VTOrc: automated failure detection and recovery · Backup engines: builtin and xtrabackup · Backup storage on S3, GCS or filesystem · RestoreFromBackup and bootstrapping a new tablet · Point-in-time recovery · Cross-cell and multi-region topologies
The day-to-day of running Vitess. Managed online DDL with its several strategies, the replication-lag throttler that keeps a migration from harming production, the Vitess Operator on Kubernetes, monitoring, upgrades, and the security and access controls a database tier needs.
Topics: Managed schema migrations and ddl_strategy options · Online DDL with vitess, gh-ost and pt-osc strategies · The lag throttler and how it paces a migration · Migration lifecycle: queued, running, complete, cancel and retry · Vitess Operator on Kubernetes: VitessCluster, cells, keyspaces · Storage classes, pod placement and resource sizing · Monitoring with Prometheus and Grafana; the metrics that matter · Upgrading Vitess and MySQL versions safely · Authentication, TLS and access control at vtgate · Troubleshooting: unhealthy tablets, stuck workflows, planning errors
We rebuild the agenda around the tools you actually run.
Request a custom agendaStand up vtgate, vttablet and a topology service, point an existing application at Vitess without touching its code, and use vtexplain to see how its queries are planned.
Analyse a real query distribution, choose a primary vindex, add a lookup vindex for the common non-key lookup, and prove the scatter rate drops.
Migrate tables into a new keyspace with traffic flowing, verify row-for-row with VDiff, switch reads then writes, then reverse the whole cutover cleanly.
Run a Reshard workflow under continuous write load, monitor copy progress and lag, verify with VDiff, stage the traffic switch and measure what clients experienced.
Trigger both a planned reparent and an emergency reparent, watch VTOrc react, then restore a fresh tablet from backup and bring it into the shard.
Deploy a sharded cluster with the Vitess Operator, wire up monitoring, run an online schema change on a large table with the throttler engaged, and perform a rolling upgrade.
Billed yearly at ₹9,996
Max 8 to 10 hours of live instruction
Full program, private instructor
8–30 engineers · custom agenda · onsite or online · PO and GST invoicing
Refunds. If we cancel or postpone a cohort, you get a full refund within 15 days. There is no money-back guarantee otherwise.
Terms. Course material remains licensed to the attendee. Read the terms.
Your data. We don't share it with third parties. Privacy policy.
Certificate of completion
The Rundeck developer session was excellent and highly engaging. I appreciated how well the session was structured, with the theoretical concepts explained clearly and in simple terms. What stood out most to me was the demo — it was both informative and enjoyable. I especially liked how Rajesh walked us through not only the happy path but also the sad path, showcasing common issues and sharing practical troubleshooting tips.
Rajesh's experience and knowledge are exceptional and we learnt invaluable practical knowledge which we can apply in our production environment. Incredibly friendly and gave us a fantastic insight both in-depth and at a high level of the Rundeck product.
Great learning experience from a very knowledgeable instructor with well-prepared course notes. The lab exercises on AWS instance work well to learn the hands-on side of the course.
Rajesh is a very good trainer I have experienced in DevSecOps training. The number of contents in different topics he has posted on the DevOpsSchool public website are amazing and user friendly for beginners and experienced professionals.
The trainer (Rajesh) provided very good sessions on SRE profession. Not only hands-on learning on the tools but also SRE mindset.
Very good training session. Well explained from the basics to the complex concepts. Also tried to cover practicals and demos within the 3 hour sessions. The learning content and videos are of a great deal of help.
| What matters | YouTube + blogs | Generic online course | Freelance marketplace | DevOpsSchool |
|---|---|---|---|---|
| Named practitioner | No | Rarely | Varies per booking | Yes — same trainer each time |
| Production experience | Unknown | Unknown | Unverified | 20 years, named employers |
| Custom agenda | No | No | Sometimes | Built from your stack |
| Onsite delivery | No | No | Sometimes | Yes |
| Lab environment | None | Sandbox that expires | Varies | Your own cloud — skill goes with you |
| Assessment | None | Quiz | Rarely | Assignments + capstone per module |
| Per-attendee certificates | No | Sometimes | Rarely | Yes |
| Corporate invoicing | No | Limited | Varies | PO and GST |
| Post-training support | None | Forum, time-limited | None | Lifetime forum access |
Tell us the team, the stack and the timeline. You'll get a straight answer, not a sales sequence.
Talk to an advisorPrefer to call or email?
More ways to reach us on the contact page.