Private corporate batches, live online cohorts and 1-on-1 mentoring in PostgreSQL operations — MVCC and vacuum, WAL and PITR, streaming replication, and query tuning — 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 PostgreSQL from the concurrency model outward: why MVCC leaves dead tuples behind, what autovacuum is actually doing, how bloat and transaction ID wraparound develop, and how the WAL underpins checkpoints, point-in-time recovery, streaming replicas and logical replication alike. Sessions run on real instances — pg_stat_statements and EXPLAIN (ANALYZE, BUFFERS) against live workloads, a rehearsed PITR, a promoted replica, and a connection pooler put in front of a server that has run out of backends.
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 PostgreSQL that means a trainer who has run it in production — PostgreSQL operations — MVCC and vacuum, WAL and PITR, streaming replication, and query tuning — 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 PostgreSQL batchPostgreSQL is an open-source object-relational database management system with a process-per-connection architecture, strict standards compliance and an extension system that lets it take on workloads well outside classic OLTP. A running instance is a postmaster supervising backend processes plus a set of background workers — the WAL writer, checkpointer, background writer, autovacuum launcher and any logical replication workers — coordinating through a shared buffer cache.
What defines PostgreSQL operationally is its concurrency model. It implements MVCC by keeping multiple row versions in the table itself, so an UPDATE writes a new tuple and leaves the old one behind. Readers never block writers and writers never block readers, but dead tuples accumulate, which makes autovacuum, bloat, transaction ID wraparound and the visibility map genuinely operational concerns rather than internals trivia. Durability comes from the write-ahead log, and that same WAL stream is what powers point-in-time recovery, streaming replicas and logical replication.
The extension surface is the second half of the story: PostGIS for spatial data, pgvector for embeddings, TimescaleDB for time series, pg_stat_statements for workload analysis, foreign data wrappers for federation. That range, plus a licence with no commercial strings, is why PostgreSQL has become the default choice for new systems and the migration target for teams leaving proprietary engines — and why infrastructure teams increasingly own one whether or not anyone on the team has a database background.
PostgreSQL has quietly become the default relational database for new systems, and the destination for a large amount of migration away from commercial engines. That means more organisations are running Postgres than have anyone who has operated it before, and the operational model is different enough from MySQL or SQL Server that intuition transfers badly.
The specific failures are consistent and expensive. Autovacuum tuned for a small instance stops keeping up on a large one, and bloat quietly doubles the size of the working set. A long-running analytics transaction on a replica holds back cleanup on the primary. Connection counts climb past what a process-per-connection server can carry, with no pooler in front. Transaction ID wraparound warnings appear in the log and get ignored until the database refuses writes. None of these are obscure — they are the standard curriculum of Postgres operations, and they are exactly what teams have never been taught.
Managed Postgres — RDS, Aurora, Cloud SQL, Azure Database — removes the host and the patching, not the database. Autovacuum settings, index design, WAL volume, replica lag, extension choices and a recovery window you have actually rehearsed are all still yours. Hiring now reflects that: platform, SRE and data-infrastructure roles routinely ask for operational Postgres depth alongside cloud and automation skills.
What a PostgreSQL instance is made of: the postmaster, one backend process per connection, and the background workers that do the real housekeeping. Cluster initialisation, the data directory layout, tablespaces, and the differences between packaged, source and container installations that matter later.
Topics: Postmaster, backends and background workers · Shared buffers, WAL buffers and per-backend memory · initdb, clusters and the data directory layout · Installation: packages, source builds and containers · Tablespaces and file layout on disk · psql as an operational tool, not just a prompt
Configuration precedence from postgresql.conf through ALTER SYSTEM to per-role and per-database settings, and which ones need a restart. Then the access path — pg_hba.conf rules read in order, authentication methods, TLS, and a role and privilege model that survives a security review.
Topics: postgresql.conf, ALTER SYSTEM and configuration precedence · Reload versus restart parameters · pg_hba.conf: rule ordering and authentication methods · TLS for client and replication connections · Roles, groups, GRANT and default privileges · Row-level security and schema-based isolation · Connection limits and why they bite
The single most important operational topic in PostgreSQL. How MVCC stores multiple row versions, why dead tuples accumulate, what autovacuum actually does and when it falls behind, how bloat develops and is measured, and why transaction ID wraparound eventually stops a database that nobody has been watching.
Topics: MVCC, tuple visibility and the visibility map · Dead tuples, HOT updates and the fillfactor lever · Autovacuum: thresholds, scale factors and cost limits · Measuring table and index bloat · VACUUM, VACUUM FULL, pg_repack and the trade-offs · Transaction ID wraparound and freeze behaviour · Long transactions and their effect on cleanup
Durability and recovery from one mechanism. How the write-ahead log works, what a checkpoint costs, WAL archiving and retention, physical backups with pg_basebackup and pgBackRest, logical dumps with pg_dump, and a point-in-time recovery performed end to end against a real timeline.
Topics: Write-ahead logging, checkpoints and full-page writes · WAL archiving, archive_command and retention · pg_basebackup and physical backup mechanics · pgBackRest or Barman for real estates · pg_dump and pg_restore: when logical is the right answer · Point-in-time recovery, recovery targets and timelines · Restore rehearsal, RPO and RTO as measured numbers
Copying a PostgreSQL cluster and surviving the loss of the primary. Streaming replication and replication slots, hot standby and the feedback trade-off, synchronous commit levels, controlled promotion and timeline divergence, then logical replication for selective and cross-version copying, and the tooling that automates failover.
Topics: Streaming replication and replication slots · Hot standby, query conflicts and hot_standby_feedback · Synchronous commit levels and their latency cost · Promotion, timelines and pg_rewind · Logical replication: publications and subscriptions · Automated failover with Patroni and etcd · Connection routing during failover
Making slow things fast with evidence rather than folklore. Reading EXPLAIN (ANALYZE, BUFFERS), understanding how the planner uses statistics and cost parameters, choosing between the index types Postgres actually offers, and using pg_stat_statements to find the queries that matter instead of the ones people complain about.
Topics: EXPLAIN (ANALYZE, BUFFERS) read line by line · Planner statistics, statistics targets and extended statistics · B-tree, GIN, GiST, BRIN and hash indexes · Partial, expression and covering indexes · work_mem, sorts, hash joins and spill to disk · pg_stat_statements and workload profiling · Declarative partitioning and partition pruning
The operational surface an infrastructure team owns. Connection pooling with PgBouncer and why a process-per-connection server needs it, the monitoring signals that matter, major-version upgrades with pg_upgrade or logical replication, extension management, and running Postgres on Kubernetes or a managed service.
Topics: PgBouncer: pooling modes and where they break · Monitoring: pg_stat views, exporters, Prometheus and Grafana · The alerts a Postgres estate actually needs · Minor patching and major-version upgrade strategies · pg_upgrade versus logical replication upgrades · Extensions: pg_stat_statements, PostGIS, pgvector, TimescaleDB · Postgres on Kubernetes and on managed services
We rebuild the agenda around the tools you actually run.
Request a custom agendaGenerate heavy update churn on a table, measure the resulting bloat, and clear it with autovacuum tuning, VACUUM FULL and pg_repack — comparing lock impact for each.
Archive WAL, take a base backup, run a destructive migration, then recover the cluster to the moment immediately before it and verify data integrity.
Build streaming replication with slots, fail the primary, promote a standby, then bring the old primary back as a replica with pg_rewind rather than a full rebuild.
Use pg_stat_statements to find the queries that dominate the workload, then fix each one with an index, a statistics change or a rewrite, proving the gain with EXPLAIN ANALYZE.
Drive a connection count past max_connections, observe the failure mode, then introduce PgBouncer in transaction mode and measure throughput and latency again.
Stand up a Patroni-managed cluster with etcd and a routing layer, kill the primary, and document exactly what the application experienced during failover.
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
I was looking to improve my understanding of AIOps, and this training helped me achieve that goal. Rajesh Kumar explained the subject in a structured and practical manner. The sessions on different AIOps concepts were informative.
I recently did a SRE Session with Rajesh Kumar from DevOps School and the session was great. Right from 1st day till day 15, we had a very interactive session. Rajesh clarified our doubts and the tool demos were excellent without any hiccups. He simplified the concepts while sticking to the content with a fine balance between theory and practice. Am convinced he is one of the best trainers for SRE & DevOps concepts.
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.
| 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.