A working publication, not a marketing surface.

The CortexRidge blog exists for one reason. Most database operational knowledge lives in the heads of engineers who fixed the same problem five times and never wrote it down. We are trying to write some of it down.

What we publish

Deep, narrow, technical writing on the operational layer of databases — PostgreSQL, MySQL, MongoDB, ClickHouse — and the practice of running them well at production scale. Diagnostic deep-dives. Honest comparisons. Postmortems we are allowed to share. The occasional founder note like this one.

We will not publish listicles, content-marketing fluff, or "Top 5 PostgreSQL tips for 2026". If a post does not teach you something a senior engineer would have to read source code to figure out on their own, we would rather not publish it.

Who writes it

Today, mostly Dinesh — fifteen years inside PostgreSQL practices at OpenSCG, Percona, and Oracle's OCI PostgreSQL team. Author of the PL/pgSQL book. Over time we expect to add guest posts from other engineers who have shipped the kind of operational depth this blog tries to capture.

Cadence

One or two posts per month. We would rather publish slowly and well than constantly and badly. RSS and the newsletter are the two best ways to follow along.

Topic suggestions

If there is a database operations topic you wish someone wrote about properly — autovacuum tuning at 100 TB, ClickHouse part-merge tuning, MongoDB WiredTiger cache eviction, MySQL InnoDB redo log sizing — write to [email protected] and we will probably pick it up.

About CortexRidge

CortexRidge is a database operations consultancy. We work with teams running PostgreSQL, MySQL, MongoDB, and ClickHouse at production scale, and we focus on the operational layer: the parts that determine whether your database is fast, durable, observable, and recoverable when things go wrong.

If your team needs a second pair of eyes on a database that has started to feel slow, a review of an architecture before you commit to it, or someone to sit with the on-call engineer through an incident — that is what we do.