Platform primer
What a relational database management system actually does
A plain walk through storage, transactions and query planning, and what a DBA, a developer and a platform engineer each keep an eye on in a smaller organisation.
How we work
Insights
Notes on relational platforms and database tooling
About this index
The Insights section collects practical articles and shorter notes on relational database platforms, cross-platform SQL tooling, open-source SQL clients and cloud-native database operations. Everything here comes from project work and from the questions clients actually ask.
Platforms
PostgreSQL, MySQL, IBM Db2 and SQL Server — the engines the work runs on.
Clients
pgAdmin, MySQL Workbench, SQL Server Management Studio and DataGrip.
Operations
Cloud-native database operations and the tooling that carries them.
What we write about
The subject matter follows the platforms we work with, and the tools built around them.
Engines
PostgreSQL, MySQL, IBM Db2 and SQL Server.
Administration clients
pgAdmin, MySQL Workbench and SQL Server Management Studio.
Developer clients
DataGrip and other query-writing environments.
Container operations
CloudNativePG and the controller-driven lifecycle around PostgreSQL.
We write for people making decisions, which shapes the level. An article on PostgreSQL administration in a containerized environment assumes you know what a database is and does not spend three paragraphs explaining SQL. An article comparing engines for a new project assumes you may never have run any of them and starts from the workload.
From the work
Automation relocates work. A controller runs the cluster lifecycle — it does not choose your indexes, your retention policy or your recovery objectives.
Teams that assume otherwise discover the gap at an inconvenient moment. That sentence shows up in almost every cloud-native engagement we run, and it shapes how the articles in that section are written.
Primers and first steps
Some pieces are groundwork, written for the reader who has inherited a system and needs to understand it before changing anything.
First steps
The first week with a PostgreSQL installation
Which parts of an installation you should not touch, why MySQL's storage engine choice matters before you tune anything, and why an untested backup is not a backup.
Our servicesHead-to-head comparisons
Comparisons stay within a category rather than reaching across it. No rankings and no scoring — the answer depends on the estate, not on the tool.
Engines
PostgreSQL against MySQL
For a new application backend: what each engine is genuinely good at, where it turns awkward, and the workload details that push the decision one way or the other.
Clients
pgAdmin against DataGrip
For teams whose work is mostly query writing: where each client sits, what it costs in attention, and when the open-source SQL client is the honest answer.
Clients
SQL Server Management Studio against a cross-platform client
For engineers who move between engines: what the first-party tool keeps, and what cross-platform support gives back when the estate is not all one vendor.
The platforms and tools pages carry the same material at more depth — clients, engines and the operations that sit around them.
See the tool comparisonsGood tool, adequate tool
A recurring question across the articles: what makes one administration tool better than another that does roughly the same job.
Truth about server state
Whether it tells you what the server actually looks like rather than a convenient summary.
Behaviour at scale
Whether it holds up when you have twenty servers instead of two.
Daily speed
Whether the people who use it every day find it faster than the alternative — a question only they can answer.
Operational fit
Whether the tool fits the operational model of the infrastructure around it. An operator that reconciles a declared state fits GitOps workflows; a tool that requires manual steps in a console does not, however good it is on its own terms.
Cloud-native database operations
Kubernetes changed what database administration looks like in a meaningful way, and CloudNativePG is one of the tools at the centre of that change for PostgreSQL.
Covered
Cluster provisioning, failover behaviour, upgrades handled by a controller, and the administrative tasks that stay manual because no automation touches them.
Outside the controller
Index design, retention policy and recovery objectives stay yours. A controller runs the lifecycle; it does not decide the shape of your data.
The recurring theme is that automation relocates work rather than removing it. Teams that assume otherwise discover the gap at an inconvenient moment, usually during an incident. The articles in this section are written to name that boundary before you reach it.
Reading the articles in order
There is no required sequence. Most visitors arrive from a search for a specific question and read one piece. If you are new to the area, the platform primers give context for everything else.
New to the area
Start with the platform primers. They give the context for everything else in the index — engines, clients and the administrative roles around them.
Deciding this quarter
Read the head-to-head pieces first. They are written around the workload rather than the feature list, so the awkward cases arrive early.
Running containers
Go to the operations notes. They cover the parts of administration that do not move anywhere once a controller takes over the lifecycle.
If you would rather ask a question directly than read around it, the contact page reaches the same people who write the articles.