Private corporate batches, live online cohorts and 1-on-1 mentoring in choosing, operating, securing and recovering the datastores a platform depends on — 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 datastore operations across engine families rather than one product at a time: how write-ahead logging and fsync define durability wherever you find them, how replication synchrony determines what a client is actually guaranteed, how working-set size and index design govern performance in relational, document and in-memory stores alike, and how a recovery objective becomes a measured number instead of an intention. Sessions run against real systems — a durability setting disproved by a failure test, a restore timed end to end, a hardening baseline applied against a published benchmark, and a datastore selection defended against the access pattern it has to serve.
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 Databases that means a trainer who has run it in production — choosing, operating, securing and recovering the datastores a platform depends on — 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 Databases batchDatabases are the stateful layer of a platform — the part that cannot be redeployed from a Git repository, scaled by adding replicas of a stateless process, or restored by re-running a pipeline. That single property is what makes operating them a distinct engineering discipline rather than a variation on running application servers, and it is what this course is about: the primitives that are common to every datastore, and the decisions that differ between them.
The landscape is genuinely varied. Relational engines such as MySQL, PostgreSQL, SQL Server and Oracle offer transactions, constraints and a query planner. Document stores such as MongoDB trade schema enforcement for flexibility and horizontal distribution. Key-value stores such as Redis put the working set in memory and make durability a configuration choice. Wide-column, search, time-series, graph and object stores each exist because a specific access pattern made the general-purpose answer expensive. Streaming platforms such as Kafka increasingly sit between them all as the system of record for change.
Underneath the variety, the same small set of mechanisms recurs. Write-ahead logging and fsync define durability. Replication defines availability, and its synchrony defines what a client is actually guaranteed after an acknowledged write. Indexes and working-set size define performance. Backup only counts once a restore has been rehearsed and timed. Access control, encryption in transit and at rest, and auditing define whether the data survives a compliance review. Learning those mechanisms once makes every specific engine — self-managed, on Kubernetes, or behind a managed service — a matter of translating known concepts into that product's vocabulary.
Two changes have made database operations an infrastructure problem rather than a specialist one. First, the dedicated DBA function has largely been absorbed into platform and SRE teams, so the people carrying the pager for a datastore usually have no database background. Second, polyglot persistence has become normal: a single product now routinely runs a relational store, a cache, a search index and a streaming platform, and no one person was hired for all four.
That combination produces a specific and expensive kind of failure. Datastores are chosen by whoever wrote the first service, on the basis of familiarity rather than access pattern. Durability settings are inherited from a quickstart guide, so a system that everyone believes is transactional is acknowledging writes it can lose. Backups exist as a scheduled job that has never been restored, so the recovery time objective is a number in a document rather than a measurement. Cross-engine questions — which store should own this data, what happens when two of them disagree, how do we migrate off this one — have no owner at all.
Managed services have made provisioning trivial and the underlying skills more valuable, not less. RDS, Aurora, Cloud SQL, Atlas, ElastiCache and MSK remove the machines; they do not choose your indexes, size your working set, set your consistency level, design your access model or rehearse your restore. The roles that now hire for this ask for exactly that: an engineer who can operate several kinds of datastore competently, reason about the trade-offs between them, and be trusted with the part of the platform that cannot be rebuilt.
A structured tour of what exists and what each family is actually for. Relational, document, key-value, wide-column, search, time-series, graph and object stores, plus streaming platforms as a system of record — compared on access pattern, consistency model, operational burden and cost, with a selection method you can apply to a real requirement.
Topics: Database fundamentals, common threats and common challenges · DBMS and RDBMS: what the relational model actually provides · Document, key-value and wide-column stores and their trade-offs · Search, time-series and graph stores as specialised answers · Streaming platforms as a system of record · Polyglot persistence and the cost of running many engines · A selection method based on access pattern and consistency need · When the boring choice is the correct one
The mechanism that recurs in every engine, taught once. Write-ahead and redo logging, buffer pools and page cache, fsync and the difference between a write reaching the operating system and reaching the disk, commit acknowledgement settings, group commit, and how to test a durability claim by pulling power rather than by reading documentation.
Topics: Write-ahead and redo logging across engines · Buffer pools, page cache and dirty page flushing · fsync, write barriers and what storage actually promises · Commit acknowledgement settings and their latency cost · Checkpointing and recovery on restart · Snapshot and append-only persistence models · Testing a durability claim by inducing failure
Availability and its consequences for correctness. Asynchronous, semi-synchronous and quorum replication; leader election and split-brain; what read-your-writes, monotonic reads and eventual consistency mean to an application; the real content of the CAP and PACELC trade-offs; and failover behaviour — automatic, manual and the failure modes of the automation itself.
Topics: Asynchronous, semi-synchronous and quorum replication · Leader election, quorum and split-brain avoidance · Consistency models an application can actually rely on · Read replicas, replica lag and stale reads · CAP and PACELC in operational terms · Automatic failover and the failure modes of failover tooling · Multi-region topologies and their latency cost · Quantifying data-loss exposure per topology
The discipline most estates think they have. Logical versus physical backup, snapshot consistency for volumes and clusters, log-based point-in-time recovery, backup verification, restore rehearsal, cross-region and cross-account copies, retention against regulatory requirement, and turning recovery objectives into measured numbers rather than aspirations.
Topics: Logical and physical backup strategies compared · Volume and cloud snapshots, and consistency across nodes · Log-based point-in-time recovery across engine families · Backup verification and automated restore testing · Restore rehearsal and measuring real RTO · Cross-region and cross-account backup copies · Retention, immutability and ransomware considerations · Recovering from logical error rather than hardware failure
Why things are slow, expressed in terms that transfer between products. Working set versus data set and the memory question that underlies most performance work, index structures and what each one is good at, query plans and cost estimation, connection management and pooling, contention and locking, and capacity planning that accounts for growth and for maintenance overhead.
Topics: Working set, data set and the memory that actually matters · Index structures: B-tree, hash, inverted, LSM and their trade-offs · Query plans, statistics and cost estimation · Connection management, pooling and why servers run out · Locking, contention and concurrency control models · Storage layer behaviour: IOPS, latency and write amplification · Benchmarking honestly and avoiding misleading results · Capacity planning and growth modelling
The module that carries most audit findings. The security issues, controls and policies a datastore owner is accountable for; authentication and least-privilege authorization; encryption in transit and at rest and where the keys live; credential handling and rotation; auditing in relational and NoSQL systems; and hardening against published benchmarks rather than opinion.
Topics: Database security issues, controls and policies · The datastore owner's accountability in a platform team · Authentication models and least-privilege authorization design · Encryption in transit, at rest, and key management · Credentials, secret storage and automated rotation · Auditing in relational databases · Auditing in NoSQL databases · Hardening against published benchmarks such as CIS · Data classification, masking and access to production data
Where stateful systems actually run now. Managed services and exactly which responsibilities they transfer, the ones they do not, and how to evaluate the cost; then running databases on Kubernetes — StatefulSets, persistent volumes and storage classes, operators and what they automate, and the honest question of when a managed service is the better engineering decision.
Topics: Managed services: what they take and what stays with you · Comparing managed offerings across engine families · Cost modelling for managed versus self-managed · StatefulSets, persistent volumes and storage classes · Database operators and what they automate · Backup, failover and upgrades under an operator · Multi-tenancy and noisy-neighbour effects · Deciding between managed, self-managed and Kubernetes-hosted
Living with the data after it exists. Schema change under load and the expand-and-contract pattern, migration tooling in a pipeline, engine and version migration with verification and cutover planning, change data capture for keeping systems in step, and the observability and on-call practice that stateful systems require.
Topics: Schema change under load and expand-and-contract · Online schema change tooling and its limits · Migrations in a deployment pipeline with rollback · Engine and version migration: planning, verification and cutover · Verifying data and query behaviour before a cutover · Change data capture and keeping systems in step · Observability for stateful systems: the signals worth alerting on · On-call practice and runbooks for datastores
We rebuild the agenda around the tools you actually run.
Request a custom agendaTake three real workloads with stated access patterns and consistency requirements, choose an engine for each, and defend it against a challenge from the room.
Configure two different engines to the settings a typical quickstart guide produces, kill nodes mid-write, and count exactly how many acknowledged writes disappeared.
Take a full backup and log stream for two engines, recover each to a point immediately before a destructive change, and publish the measured recovery time.
Apply a CIS-style hardening benchmark to a relational and a NoSQL datastore, document every deviation with a justification, and produce an audit-ready report.
Rename and retype a column on a hot table using expand-and-contract with dual writes, verify data equivalence, and roll back cleanly at each stage.
Take a multi-engine estate through selection review, a durability audit, a restore drill, a hardening pass and a migration plan, and present the result as a data platform standard.
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 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.
Basics explanation was exemplary from Rajesh where he dealt with complicated topics to be simple. Great learning stuff personally for me.
Very detailed explanation and has lots of patience in attending the questionnaire. Thanks again for your wonderful sessions.
Good discussion, helped us to understand different tools in SRE.
Got good lab sessions which kept the new DevOps tool learnings to the point and it helped a lot in my career.
| 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.