Private corporate batches, live online cohorts and 1-on-1 mentoring in column-oriented OLAP at scale — MergeTree design, ingestion, query performance, sharding and replication — 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 ClickHouse around physical layout rather than SQL syntax — the ORDER BY key and sparse primary index first, because that single decision determines how much data every future query reads, then partitioning, codecs and the MergeTree variant that matches the write pattern. Ingestion is taught as a parts problem: batch sizing, async inserts and why a thousand small writes a second will eventually stop a cluster. Query work is done live against EXPLAIN and the system tables, comparing granules read before and after a change, and cluster modules cover sharding, ReplicatedMergeTree and ClickHouse Keeper through deliberate node loss and recovery rather than through diagrams.
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 ClickHouse that means a trainer who has run it in production — column-oriented OLAP at scale — MergeTree design, ingestion, query performance, sharding and replication — 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 ClickHouse batchClickHouse is an open-source column-oriented database management system built for analytical queries over very large tables. Instead of storing rows together, it stores each column in its own compressed stream, so a query touching three columns of a two-hundred-column table reads only those three. Combined with vectorised execution — processing data in blocks rather than row at a time — that is why aggregations over billions of rows return in a fraction of a second on hardware that would defeat a row-store.
The engine that makes this work is the MergeTree family. Data is written as immutable parts that background threads continuously merge; the ORDER BY key determines physical sort order and populates a sparse primary index that lets the engine skip whole granules of data rather than scanning them. Partitioning organises parts for pruning and for cheap drops by time. Specialised engines in the same family change merge behaviour: ReplacingMergeTree deduplicates by key, SummingMergeTree and AggregatingMergeTree pre-aggregate, and CollapsingMergeTree handles mutable rows. Codecs such as Delta, DoubleDelta, Gorilla and T64 layered under LZ4 or ZSTD cut storage further, and LowCardinality changes the physical representation of repetitive strings.
At scale, tables are sharded across nodes and read through a Distributed table, and each shard is replicated with ReplicatedMergeTree coordinated by ClickHouse Keeper. Around the core, table engines and integrations pull data directly from Kafka, S3, PostgreSQL and MySQL; materialized views transform on insert; projections and data-skipping indexes accelerate access paths the sort key cannot serve; and dictionaries provide fast key-value lookups for joins ClickHouse would otherwise do badly.
Observability, product analytics, security telemetry, ad tech and financial time series have all converged on the same shape of problem: enormous append-heavy datasets that must be queried interactively, and a bill that must not scale linearly with volume. ClickHouse is the system organisations increasingly land on when Elasticsearch becomes too expensive for aggregation, PostgreSQL cannot keep up with the scan volume, or a cloud warehouse's per-query pricing stops making sense.
Adoption has outrun expertise. ClickHouse is easy to start — a single binary, familiar SQL — and unforgiving afterwards. The most common production failures are all design failures made in the first week: an ORDER BY key chosen to match a WHERE clause rather than the access pattern, partitioning by a high-cardinality column, thousands of tiny inserts creating too many parts, JOINs written as though the planner will optimise them, and mutations used as though they were UPDATE statements.
That gap is what employers are hiring against. The demand is not for people who can write SELECT against ClickHouse; it is for people who can design the sort key and partitioning for a known query pattern, size ingestion batches, decide between a materialized view and a projection, and run a replicated cluster through a node loss without data divergence.
Why a column store is fast, stated precisely enough to design against. Row versus column layout, compression and vectorised execution, the workloads ClickHouse is built for and the ones it is genuinely bad at, and an honest comparison with PostgreSQL, Elasticsearch and cloud warehouses so the choice is made deliberately.
Topics: Row-store versus column-store physical layout · Compression and vectorised block execution · OLAP versus OLTP workload characteristics · What ClickHouse does badly: point updates, deletes, complex joins, high concurrency · Comparison with PostgreSQL, Elasticsearch, Druid and cloud warehouses · Deployment options: self-managed, ClickHouse Cloud, containers, Kubernetes operator · Hardware profile: CPU, memory, disk and what actually limits throughput
A working server and the ability to reason about its configuration. Installation and directory layout, the split between server settings and user settings, the profiles and quotas system, the native and HTTP interfaces, input and output formats, and the SQL dialect differences that trip up newcomers.
Topics: Installation, directory layout and the config.d/users.d override pattern · Server configuration versus user settings and settings profiles · clickhouse-client, HTTP interface, and the native protocol · Input and output formats: CSV, JSONEachRow, Parquet, Native · SQL dialect specifics: functions, arrays, nullable behaviour, type strictness · Data types: integers, Decimal, DateTime64, Enum, Array, Map, Tuple, Nested · clickhouse-local for querying files without a server · Log files, error messages and how to read them
The highest-leverage decisions in the entire system, made before any data is loaded. How the sparse primary index derives from ORDER BY and how granules are skipped, choosing key column order from real query predicates, then data type selection, LowCardinality and column codecs that determine how much disk each column costs.
Topics: ORDER BY, PRIMARY KEY, and the sparse index structure · Granules, index_granularity and how skipping actually works · Choosing key column order from cardinality and query predicates · Why the sort key is not just the WHERE clause · LowCardinality: when it helps and when it costs · Codecs: LZ4 vs ZSTD, Delta, DoubleDelta, Gorilla, T64 · Nullable columns and their overhead · Denormalisation, arrays and Nested as alternatives to joins · Reading system.parts to see the result of your choices
How data physically lives and changes. Parts and background merges, partitioning done for pruning and lifecycle rather than out of habit, TTL for expiry and tiered storage, the specialised MergeTree engines and their merge semantics, and mutations and lightweight deletes with their true cost.
Topics: Parts, merges, merge selection and the background pool · PARTITION BY: pruning, DROP PARTITION, and the too-many-parts failure · TTL for row expiry, column expiry and moving data between disks · Storage policies and tiered hot/cold volumes · ReplacingMergeTree: deduplication semantics and FINAL · SummingMergeTree and AggregatingMergeTree pre-aggregation · CollapsingMergeTree and VersionedCollapsingMergeTree for mutable rows · Mutations: ALTER UPDATE/DELETE and why they rewrite parts · Lightweight deletes and deletion masks
Writing into ClickHouse without destroying it. Why insert batch size is the single most important ingestion parameter, async inserts and their durability trade-off, the Kafka and S3 table engines with materialized views as the consumption pattern, dictionaries for lookups, and deduplication on retry.
Topics: Insert batching: block size, frequency and the parts budget · Asynchronous inserts, buffering and the durability trade-off · Buffer tables and when they are still appropriate · Kafka engine plus materialized view consumption pattern · S3, URL, File and HDFS table engines for bulk and federated reads · Integration engines for PostgreSQL and MySQL, and CDC ingestion · Dictionaries: sources, layouts, lifetimes and dictGet lookups · Insert deduplication, idempotency and safe retries · Backfill and reprocessing strategies without downtime
Making queries fast with evidence. Reading EXPLAIN and the system tables to see what was actually read, then the acceleration structures for access paths the sort key cannot serve — data-skipping indexes, projections and materialized views — plus join strategy, aggregation functions and memory limits.
Topics: EXPLAIN, EXPLAIN PIPELINE and EXPLAIN ESTIMATE · system.query_log, query_thread_log and trace_log analysis · Data-skipping indexes: minmax, set, bloom_filter, tokenbf and ngrambf · Projections: what they cost and when they beat a materialized view · Incremental materialized views for pre-aggregation · Aggregate functions, combinators and AggregateFunction state columns · JOIN algorithms, join order and why dictionaries often beat joins · Approximate functions: uniq family, quantile family and their trade-offs · Memory limits, max_threads, and query complexity settings · Prewhere, index hints and query rewriting patterns
Scaling beyond one machine and surviving the loss of one. Cluster topology and the cluster definition, Distributed tables and how reads and writes fan out, sharding key choice, ReplicatedMergeTree and the replication log, ClickHouse Keeper as the coordination layer, and consistency behaviour during failure.
Topics: Cluster configuration, shards, replicas and macros · Distributed table engine: read fan-out and write routing · Sharding key selection and data skew across shards · ReplicatedMergeTree, the replication queue and replica lag · ClickHouse Keeper versus ZooKeeper: quorum, sizing, monitoring · Insert quorum, consistency settings and read-after-write behaviour · Distributed query execution, GLOBAL IN and JOIN across shards · Adding and removing shards, and resharding strategies · Node loss, recovery, and detecting divergent replicas
The day-two work. Monitoring from system tables and exported metrics, backup and restore that has actually been tested, RBAC, quotas and row policies, version upgrades on a replicated cluster, capacity planning, and a realistic view of migrating onto ClickHouse from another system.
Topics: System tables as the monitoring source: metrics, events, asynchronous_metrics, parts, merges · Prometheus and Grafana dashboards, and the alerts worth having · Backup and restore: BACKUP/RESTORE, snapshots and object-storage targets · Disaster recovery and rebuilding a replica from scratch · RBAC: users, roles, grants, row policies and quotas · Upgrades on a replicated cluster and version compatibility · Capacity planning: disk, memory, CPU and merge throughput · Common production incidents and their signatures · Migration from PostgreSQL, Elasticsearch or a cloud warehouse · ClickHouse Cloud and the Kubernetes operator as operating models
We rebuild the agenda around the tools you actually run.
Request a custom agendaDesign two ORDER BY keys for the same query pattern, load identical data into both, and compare granules read, query time and disk footprint.
Deliberately trigger a too-many-parts failure with high-frequency small inserts, then fix it with batching and async inserts and measure the parts rate.
Build a Kafka engine table with a materialized view into MergeTree, handle a consumer restart, and prove no duplicates or gaps in the result.
Take a slow analytical query and cut rows read tenfold using skip indexes, projections or a rewritten predicate, proving each step from system.query_log.
Run a sharded, replicated cluster with ClickHouse Keeper, kill a replica during ingestion, and verify recovery with no divergence or data loss.
Take a stated event rate and query pattern, design schema, ingestion and cluster topology, load it, and defend the design with measured numbers.
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
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.
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.
| 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.