Published 2026-04-22
tag(s): #random-thoughts #programming
This morning I was chatting with my boss. He was sharing some stories of his time at DEC, and
the early days of our current employer.
He told me about the database system he was working on at DEC, that was
targeting VMS but then they wanted it to
run in Ultrix too so there was a team
tasked with creating an abstraction layer, and this team faced a lot of challenged because of
how different the systems were.
It is so cool to hear of someone who was there when all these things were happening
:)
Also, the compatibility layer thing reminded me of Wine/Proton.
And from there, the conversation flowed to this post's topic, which was the effort to make early iterations of our code database agnostic. This left architectural marks in our systems, yet as of today, more than 20 years later, we are still "stuck" with the same database.[1]
The thing is, we paid a big price for a feature that we never needed. The goal is good, don't
take me wrong. Being tied to a vendor is always a risk. But the work needed to stay agnostic
is rarely worth it: you usually don't move to another database.
And if you do, it better be no more than a couple years later, or the effort will be
substantial even with all your precautions. Proprietary bits of SQL will make it into the
codebase, most of the times without even realizing.
If not the code itself, differences in DB engines will for sure cause a few surprises and need
adjustment. You can shield yourself from this by using the most basic features, but it is not
bulletproof.
The conversation reminded me of a previous job were we tried to be cloud agnostic. It is hard,
since there are slight differences here and there in how "the same" product is used in
each vendor.
Just like with databases, the best way to stay agnostic is to use the lowest common
denominator of features, and in the same way, you might depend on the specific behaviour of a
vendor without even realizing.
Unless you stay vigilant, and more or less constantly try your systems in more than one vendor, you will end up suffering if you have to move. The amount of work will scale pretty linearly with how long since you last tried your allegedly (hopefully?) agnostic code.
And that's my current stance.
Unless you have a real need (or the willpower) to run your stuff in two or more DBs/cloud
providers/whatever else I can't think of now at all times, trying to stay agnostic is
not worth it.
It usually influences your architecture, which is not great, and there's a chance that it
never happens. And even if you do make the move down the line, it will take some effort
anyway, is it worth the trade off? Aiming to use only the most basic features just to prevent
lock-in will handicap your progress, which is not a good idea in the early stages of a project
anyway.
Unless it is a primary feature (say, your product gets deployed in clients with different DBs,
or is it mean to run in the cloud provider that your client choses) then just pick one and get
to work.