The real OPEX cost of the wrong open source choice

Free to download, expensive to run

Open source is not free! The licence is, but the hours your team spends making it work are not.

At dbi services we love open source. We run PostgreSQL, Kafka and Kubernetes for many customers and we contribute where we can. But over the last years I see the same story again and again: a company picks an open source tool because there is no licence to pay, and then spends months building, tuning and debugging something that was never designed for their use case.

On the budget slide it looks great. No CAPEX. But nobody puts the OPEX on that slide, and that is where the real bill is!

A typical case: Debezium between two database engines

The requirement sounds simple. Replicate data from Oracle to PostgreSQL, or from SQL Server to something else, with low latency.

Someone finds Debezium. It is a great project for change data capture into Kafka. So the team starts, and quickly the architecture looks like this:

• 1. Debezium with a source connector reading the redo logs or the transaction log
• 2. A Kafka cluster, plus Kafka Connect
• 3. A schema registry, because the data types have to survive the trip
• 4. A sink connector, often with custom code, to write into the target engine
• Monitoring for all of the above

For a use case that is “copy these tables from A to B”, that is five new components to install, secure, patch and understand. And then the real fun starts: data type mapping between engines, DDL changes on the source, LOB columns, initial loads of big tables, connector restarts that replay or lose events. Every one of these is solvable. Every one of these costs days.

Where the money really goes

The cost is not in one big invoice. It is spread over many small things that nobody adds up.

• Build time. Weeks or months of senior engineers wiring components together instead of delivering business value.
• Troubleshooting. When replication lags at 2am, who knows Kafka Connect internals well enough to fix it? Usually one person.
• Knowledge silo. That one person becomes the system. When they go on holiday or leave the company, you have a production pipeline nobody understands.
• Upgrades. Five components means five release cycles, five sets of breaking changes, five compatibility matrices to check.
• Support. Community forums are great, but they do not have an SLA. Commercial support for the stack exists, and then it is not free anymore either.
• Hidden cost. Every hour spent on plumbing is an hour not spent on the project the replication was supposed to enable..

Let’s do the maths over three years

Over three years, the “free” option can easily cost more than the tool with a licence. Here is a simple example, with an internal cost of CHF 1’000 per engineer day. The numbers are illustrative, but they are close to what we see in real projects.

And this table does not even include the risk of the key person leaving!

This is not an anti open source post

The problem is not open source. The problem is choosing a tool for the wrong reason.

Debezium is the right choice when you already run Kafka, you have people who know it, and you need events flowing to many consumers. It is also the right choice when the goal is not just syncing two databases, but turning raw data changes into meaningful business events (order placed, inventory updated, customer status changed, invoice issued) that multiple downstream systems can react to independently. In that context it is excellent. It is the wrong choice when the only need is to keep two databases in sync and nobody in the team has ever operated Kafka.

The same applies to many other tools. The question is never “open source or not”. The question is “what will this cost us to run, every day, for the next three years?”