3 ms·

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

by edoceo 6y ago

TimTheTinker 6y ago
One never knows what the future may bring. Long-lived OSS software is a relatively stable bet, but the point still stands.
- rootsofallevil 6y ago
  >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
- jacques_chester 6y ago
  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.
  - TimTheTinker 6y ago
    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).
  - fulafel 6y ago
    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.
- pydry 6y ago
  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.
rzzzt 6y ago
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.
paulryanrogers 6y ago
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.
majkinetor 6y ago
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.

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

by edoceo 6y ago

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

One never knows what the future may bring. Long-lived OSS software is a relatively stable bet, but the point still stands.

rootsofallevil 6y ago
>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
jacques_chester 6y ago
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.
- TimTheTinker 6y ago
  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).
- fulafel 6y ago
  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.
pydry 6y ago
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.

rzzzt 6y ago

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.

paulryanrogers 6y ago

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.

majkinetor 6y ago

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.