Hacker News Reader

Comment by edoceo | Hacker News Reader

Yea, 20+ years on PostgreSQL. Why would I change my DB away from the perfect one?

IME, because client asked for the different one for whatever reason and is willing to pay for higher development cost.

You can argue about that just the same as when client needs a feature X.

In my case, I was very often getting away with YAGNI or 'how about we implement nightly sync from pg to oracle' but not always.

Self-hosted, low volume or demo installations can benefit from a lightweight database (that is also in-process, so the user does not have to install and maintain it) like SQLite, H2 or Derby.

One never knows what the future may bring.

Long-lived OSS software is a relatively stable bet, but the point still stands.

>One never knows what the future may bring.

Exactly, so make the changes when you need them, otherwise you are relying on hitting the abstraction lottery

Maintaining database abstraction layers and the like is a real option used to hedge the risk of the holdup problem. But like any real option, it has a carrying cost. That means it's an economic question, there is no purely technical rule that can give you a robust answer to whether or not to abstract something away.

I feel the industry has a long hangover from the 80s and 90s in terms of the holdup problem. Oracle, basically, created a massive externality of anxiety about vendor lockin that continues to impose drag to this day.

Agreed. “Our software currently runs on Oracle but can be switched to MS SQL Server or DB2 with about a day’s work” used to be an admirable and economically valuable statement.

In the majority of cases, I think a simple “runs on Postgres” is even more valuable today (unless your product is a database abstraction layer).

There are complexity limits past which we can't really build or extend applications short of big rewrites. I guess we can describe this in terms of economics but I feel it's not doing the issue justice. And it's often better to spend the complexity budget on domain problems.

Decoupling your data model from postgres because you "might" need to swap database is a bet I've seen taken many times but it's never one I've seen paid off.

This is a clear example of where YAGNI applies, I think.

Extra work plus extra boilerplate to maintain. No payoff.

That said, extra code + boilerplate is a great way to treat riskier software.

Also love Pg and using flavor specific features where they deliver tangible value. That said, if a team maintains multiple flavors often then an abstraction can improve quality of life.

Reply on news.ycombinator.com