Welcome to CortexRidge — fifteen years of databases, end to end

For the past fifteen years we have built and operated database systems at companies that take databases seriously — Oracle Cloud, AWS, OpenSCG, EnterpriseDB, and Tessell. Each organization was a different journey, and each one taught us something we could not have learned anywhere else.

We have built managed PostgreSQL services from scratch, end to end. We have shipped scalable monitoring systems and run them in production. We have led complex database migrations — between versions, between vendors, and across cloud boundaries. We have contributed back to the open source community, with both code and with tools we built internally and later released for everyone to use.

The work itself changes from engagement to engagement. What does not change is leadership — the through-line of these fifteen years. We learned it from the leaders we worked under, refined it as we grew teams of our own, and we are now sharpening it in the direction we want to take it.

Why we are doing this now#

CortexRidge exists to bring real, lived-in value to the people who actually work with databases day to day — developers, DBAs, SREs, and AI engineers. The hardest battles we have won were the immersive ones: the engagements that took years, the ones that are still going. Those battles are where the real learning lives. They are also where most consultancies do not show up.

We wrote books along the way — PostgreSQL PL/pgSQL Developer Guide and PostgreSQL High Performance Cookbook — both written for the DBAs and migration engineers doing the actual operational work. We have spoken in community forums on behalf of the organizations we worked at, and we have tried to leave each community a little better-informed than we found it.

Most database problems are not really database problems#

In our experience, every customer’s problem looks unique on the surface and turns out, on closer inspection, to be a quiet variation on the same theme: scale, and the performance behind it.

A recent example. We worked with a stock-market platform whose dashboard was struggling at 2,000 transactions per second. Their target was 10,000. The fix was not more database instances or bigger hardware — it was a careful, end-to-end rethink of how the application talked to the database, how the database was tuned, and how the system absorbed load as a whole. We took them past their target.

The CortexRidge thesis#

CortexRidge exists to close that gap. The thesis is simple: developers should understand the database well enough to design for it, and DBAs should understand what the application is actually doing. When that understanding is shared across both sides of the system, problems that used to take quarters get resolved in weeks.

We work in two modes.

Diagnosis — short, intensive engagements where a team has a specific problem: a slow query, a vacuum that will not catch up, a replica that drifts under load, a migration nobody trusts to run on a Saturday. We come in, instrument what needs instrumenting, identify the root cause, and leave a runbook behind.

Build — longer engagements where we partner with the team to design a database tier they can grow into. Schema review, replication topology, backup and restore strategy, observability, capacity planning — the rigorous parts that decide whether the next two years are smooth or turbulent.

Alongside both, we write, speak, and contribute to open source — including this blog. That work is not billable. It is how we stay current, and how we give back to the community that shaped us.

The principle behind all of it is the same: end-to-end technical solutions, not just one slice of the stack.

What is coming next#

We are close to releasing something we have been building quietly — a product for the people who work with databases day to day: developers, DBAs, SREs, and AI engineers. We have not seen anything quite like it. It will ship in the next few weeks.

This blog will be the home for both — the consulting work, and the product as it ships. Subscribe, forward the next post to whoever on your team keeps the database running, and tell us what you would like us to write about.

Database operations. End to end. Elevated.

— Dinesh