Comparing the platforms and tools we work with
No two database estates look alike, and the right tool depends on what you already run. Start with the platforms we support, then see which administration tool fits the people who will actually operate it.
Compare the stackThe estate, read as a rack
Eight platforms and tools, and what each one is actually for
Every row below is something we deploy, administer or write queries against. The tooling column names the administration client we would reach for; the last column is where the choice usually lands.
PostgreSQL
Application backends and analytics; extensible, standards-friendly SQL that travels between systems with less rewriting.
pgAdmin for administration, CloudNativePG when it runs on Kubernetes.
Leads on extensibility and portable SQL.
MySQL
Web applications, LAMP-style stacks and managed hosting. Simplicity is earned; character sets and storage engines are where it surprises people.
MySQL Workbench, a vendor-supported visual tool bundled into most workflows.
Leads on simplicity and managed hosting breadth.
IBM Db2
Regulated and long-lived enterprise estates, often mainframe-adjacent and transactional. Usually managed alongside something newer.
Vendor-supplied administration console, with monitoring coverage across the estate.
Leads where continuity and regulation outweigh migration.
SQL Server
The centre of gravity where Microsoft already runs the shop — administration, querying and monitoring in one ecosystem.
SQL Server Management Studio, highlighted in Microsoft's own SQL tools overview.
Leads inside a Microsoft-centred estate.
DataGrip
Developer-shaped work: composing and refactoring SQL across more than one engine, where code intelligence matters more than server configuration.
It is the client — a JetBrains SQL IDE that speaks to several database systems.
Fits people who write queries all day.
Rows are ordered as an estate is usually read, not as a ranking. A team running SQL Server with SSMS and a newer PostgreSQL service with pgAdmin is a normal shape, and the two toolsets do not compete for the same desk.
Four layers, one estate
Reading the same rack by the layer you are asking about
Schema design, query behaviour, backup and recovery, and day-to-day operations are four separate conversations. Switch the layer and the tooling column answers that conversation only.
- Schema design
- Modelling and structure — how tables relate, what an index costs, and what the constraint set actually enforces.
- DataGrip · MySQL Workbench
- Query behaviour
- What the engine does under load, which plans it picks, and where a rewritten statement changes the shape of the work.
- pgAdmin · DataGrip
- Backup and recovery
- Whether a restore has been rehearsed, how long it takes, and who is on the other end of the pager when it is not.
- pgAdmin · CloudNativePG
- Day-to-day operations
- Server configuration, user and permission management, patching windows, and the failover that either works or does not.
- SSMS · pgAdmin
Platform notes
What we would tell a team before they pick
These are notes from working estates rather than feature comparisons. Each one answers a question that tends to come up late, after the engine choice has already been made.
The engine is the smaller half of the decision
Choosing a database engine is a real decision, but it is rarely the one that hurts. The larger half is who keeps it running: whether the people on call already know the engine, whether the wrote-down procedures actually match what happens at three in the morning, and whether anyone has restored a backup outside a maintenance window. A team that knows MySQL well will get further with it than a team that picked PostgreSQL because a comparison table said so.
A Kubernetes operator is not Kubernetes experience
CloudNativePG moves cluster provisioning, failover and rolling upgrades into a controller, and that genuinely changes what administration means. It does not create the operational knowledge to run it. Adopting the operator without container experience tends to move the failure from the database to the platform, which is not obviously an improvement.
The tooling usually outpaces the practice, or lags behind it
Two failure shapes show up repeatedly. The first is a team with a modern stack they do not yet understand, running an operator nobody has debugged. The second is the reverse: a well-practised team held back by an administration client that only covers half the estate. Both are fixable, but only once they are named.
Mixed estates are the normal case, not the exception
An organisation running IBM Db2 is usually running something else as well, and an organisation on PostgreSQL is often running SQL Server somewhere. The useful question is not whether Db2 should be replaced but how the estate is managed as a whole, with consistent monitoring and a clear picture of where data flows between systems.
Four elevations of one rack
The same estate, drawn four times
Each plate is an engineer's elevation rather than a screenshot. They show what the layer touches, not what a console looks like on a good day.
Schema
Modelling
Where the shape of the data is decided. DataGrip for cross-engine work, MySQL Workbench when the estate is MySQL throughout.
Query
Reading plans
What the engine does under load. pgAdmin for PostgreSQL, DataGrip where the same query has to be compared across engines.
Backup
Recovery
Whether a restore has been rehearsed. pgAdmin for scheduled dumps, CloudNativePG where backup is part of the cluster controller.
Ops
Running it
Users, permissions, patching windows, failover. SSMS inside a Microsoft estate; pgAdmin and CloudNativePG elsewhere.
Where the tools meet the desk
How to compare engines for a new project
Start with the SQL dialect your application needs and how portable you want it to be. Then look at who will operate the database and what they already know. Then look at hosting options and cost structure, including what a managed service would replace.
- 1 — The dialect your app needsWritten first, because it is the one thing migration rarely forgives.
- 2 — Who will operate itThe team that already knows MySQL often gets further with it than the one chasing a comparison table.
- 3 — Hosting and cost structureIncluding what a managed service would replace — patching, backups, failover.
- 4 — The administration clientAn IDE for people who write queries all day; an admin console for backups and user management.
Questions we get
Before you standardise on one engine
Three questions that come up in almost every first conversation about a database estate.
Which engine fits a mixed Microsoft and open-source environment best?
No single engine covers both sides well, which is why mixed estates are normal. The useful work is mapping workloads to engines rather than standardising on one, and choosing administration tools that make the resulting estate manageable.
When is a managed cloud database better than self-hosting?
When routine operations like patching, backups and failover are consistently slipping, and the cost of a team's attention exceeds the managed fee. Schema design and query performance stay with you regardless.
What is the difference between a DBMS, a database client and a monitoring tool?
The DBMS stores and serves the data. A client is how you interact with it, such as pgAdmin, MySQL Workbench, SSMS or DataGrip. A monitoring tool observes the running system over time, which is a separate concern from querying it.
Describe your project
Tell us what you already run and we will tell you where the tooling is fighting you
Most of the work starts the same way: a short conversation about the engines currently in production, who operates them, and which administration client the team actually opens. We publish what we can about that process, and we answer what we cannot publish directly.
- Company
- HORIZONIS HOLDINGS BV
- Address
- Avenue Louise 143, 1050 Brussels, Belgium
- Telephone
- +3225244847
- [email protected]
- Hours
- Monday to Friday, 9:00 AM – 6:00 PM