I make PostgreSQL work at production scale. Everything here is written from the pager alerts, not the docs: every case study, course module and article cost an incident first, and these are the notes I wish I'd had before it did.
Credentials
Senior Software Engineer, Supra (via CodeZeros)
Architect of SupraScan, Supra Blockchain's native explorer and indexer: 500–1,000 TPS on a PostgreSQL database that grew to 10 TB, now 2.7 TB.
6+ years in production engineering
From enterprise B2B platforms (Rapidops — Kroger, Salesmate CRM) to high-throughput Web3 indexing infrastructure.
Author, In-Depth course series
PostgreSQL, Node.js, Next.js, Redis, Docker, and Data Structures & Algorithms — free, documentation-style courses built from production incidents.
B.E. in Information Technology
Truba Institute of Engineering and Information Technology, Bhopal — 7.76 CGPA.
Case studies
All 12Indexing a Blockchain in Real Time, at ScaleA blockchain never pauses for maintenance. Here's how SupraScan's indexer stays caught up, decomposes every transaction into a dozen relational tables, and survives its own concurrency bugs without losing data.Scaling a Blockchain Database From a Single Partition to 4.6 TBA partition strategy that worked in 2021 became a 10TB liability by 2026. Here's the five-stage evolution that got it back under control, the outage the last stage caused, and the storage arc from 10TB avoided to 4.6TB today.Exact Analytics in 12KB: Hardening a Wallet-Uniqueness SystemHyperLogLog gets you exact distinct-wallet counts at near-zero memory cost. The hard part is not the algorithm, it's keeping it correct under concurrent production writes. Five real bugs, one week, five different ways correctness quietly slips.Concurrency Design Under High TPS: Moving Wallet Counters Off Database TriggersA 3-4 day indexer lag traced back to four wallets and a database trigger. The fix moved counting logic out of the database entirely, and a routine check-with-the-docs step turned up an architectural assumption that had been wrong all along.
Courses I've written
All coursesPostgreSQL In-DepthFrom First Query to Production ArchitectureNode.js In-DepthFrom Runtime Basics to High-Throughput Distributed SystemsNext.js In-DepthFrom First Route to Production-Grade ArchitectureRedis In-DepthFrom Runtime Basics to Distributed Architecture at ScaleMaster JavaScript TestingFrom Unit Tests to End-to-End MasteryDocker In-DepthFrom Container Internals to Production SaaS DeploymentData Structures and Algorithms In-DepthFrom First Principles to Architect-Level Systems ThinkingSystem Design In-DepthFrom the Silicon to the Multi-Region Ledger
Recent articles
All articlesHow a B-Tree Really Reads, Inserts, Updates and Deletes (and Where It Fails a Blockchain Indexer)A B-tree is cheap to search and expensive to keep sorted. Here’s what reads, inserts, updates and deletes actually do inside one in PostgreSQL, and how that should decide the index on every table of a blockchain indexer, from wallet history to balances to NFTs.Turning Your Blockchain Indexer Into a Paid API Without Slowing Down Your ExplorerTurning blockchain indexer data into a paid API is easy. Keeping API traffic from slowing your explorer or ingestion is the hard part. This post presents a production architecture using replica pools, read models, finality-aware caching, Redis quotas and per-plan bulkheads.Your Postgres Indexes Can Break Without a Single Line of Code ChangingYou bumped the base image or rebuilt a replica on a newer OS. No deploy, no migration. Then a unique index lets in a duplicate and an indexed lookup misses a row you can see. Here's how collation drift breaks B-tree indexes, how to prove it with amcheck, and the fix order that doesn't silence the only alarm.Your UUID Primary Keys Are Quietly Taxing Every InsertRandom UUIDv4 keys look harmless until the table grows. Every insert lands on a random B-tree leaf page, the index outgrows the buffer cache, pages split half-empty, and full-page writes inflate WAL after every checkpoint. A 10M-row PostgreSQL 18 benchmark shows the cost, and why native uuidv7() recovers almost all of it without giving up distributed ID generation.The TOAST Tax: How Unbounded JSONB Arrays Cost My Blockchain Indexer 5TBOur PostgreSQL blockchain indexer's TOAST table grew past 5TB because unbounded JSONB arrays kept getting bigger. Here's what TOAST was costing us, how to measure it, and how we moved hot JSONB fields into normal columns without taking the indexer offline.Every Postgres Write Triggers Five Background Processes. Here's What Each One Actually Does.An UPDATE returns in two milliseconds, but underneath, Postgres just ran WAL logging, checkpoint bookkeeping, wait-event tracking, vacuum, and ANALYZE to make that write durable, recoverable, and still fast to plan. Here's what each of those five processes actually does, and which one is usually behind the latency spike that has no slow query in sight.