4 ms·

> In all my career (started coding in 1986) I keep hearing about 1), worked in several RDMS agnostic products, never saw a customer actually migrating into anot

> In all my career (started coding in 1986) I keep hearing about 1), worked in several RDMS agnostic products, never saw a customer actually migrating into another RDMS. no kidding, you hear about this way more than it actually comes up. especially for the folks who treat the RDBMS as a dumb store and don't use the features.

yamtaddle 3y ago
I've seen apps replaced/rewritten on top of a database multiple times. I've seen it be very convenient to have enough logic in the database that it was easy and low-risk to have multiple programs share a database, without sharing much or any code. I've never actually seen a database system get swapped out, in real life. The only two ways I can imagine it happening are: 1) someone made a colossal fuck-up picking the DB software—and, it'd have to be really bad, I've seen a lot of applications stick with a mistake there and just deal with the pain; or 2) extreme hockey-stick growth (which, file under "good problem to have, and we can afford a proper migration") In fact, #2 is usually addressable with supplementary databases, a little re-structuring of the existing database, and smarter caching, except in super-rare scenarios of truly wild growth or unusual access patterns. More often than not, even then, the original database sticks around in some form or another.
- scarface74 3y ago
  > I've never actually seen a database system get swapped out, in real life https://aws.amazon.com/blogs/aws/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/ https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
- lenkite 3y ago
  Shows how different the software ecosystem is. For a product that I worked on - during a decade, the DB system got swapped out 4 times - all driven by customer demand. The app software evolved continuously but the DB was hard changed - with all relevant schema and data migration applied during the upgrade process.
- bborud 3y ago
  The phrase "to have multiple programs share a database" says a lot about what school of thought one belongs to in terms of architecture. Using the database as the integration point went out of fashion a bit over 20 years ago. And for good reason. It is not a good integration pattern. It makes the implementation the integration interface rather than using a tightly controlled abstraction that can be kept narrow and preserve degrees of freedom for future evolution. And as you allude to: it gets worse because you have to move more application knowledge and logic into the database to make sure applications don't mess it up. In fact, this approach is so bad that Amazon's CEO explicitly forbade it at Amazon (Bezos API Mandate, 2002). How often do you see CEOs, even of tech companies, find an integration pattern so counterproductive and dangerous they announce to the company that they will fire anyone using it? I would say that about 60-70% of projects I've worked on in the last decade have switched databases at least once. One project had support for 5-6 databases and used three different databases in production over a span of 5 years. Adding support for them had fairly low cost (because the internal design made it easy) and it gave us the opportunity to try several things in production, at scale, and then choose what produced the best results. This is a lot better than just choosing something up front and sticking with it because you'll have the data to make an informed choice.

yamtaddle 3y ago

I've seen apps replaced/rewritten on top of a database multiple times. I've seen it be very convenient to have enough logic in the database that it was easy and low-risk to have multiple programs share a database, without sharing much or any code. I've never actually seen a database system get swapped out, in real life. The only two ways I can imagine it happening are: 1) someone made a colossal fuck-up picking the DB software—and, it'd have to be really bad, I've seen a lot of applications stick with a mistake there and just deal with the pain; or 2) extreme hockey-stick growth (which, file under "good problem to have, and we can afford a proper migration") In fact, #2 is usually addressable with supplementary databases, a little re-structuring of the existing database, and smarter caching, except in super-rare scenarios of truly wild growth or unusual access patterns. More often than not, even then, the original database sticks around in some form or another.

scarface74 3y ago
> I've never actually seen a database system get swapped out, in real life https://aws.amazon.com/blogs/aws/migration-complete-amazons-consumer-business-just-turned-off-its-final-oracle-database/ https://aws.amazon.com/blogs/aws/migration-complete-amazons-...
lenkite 3y ago
Shows how different the software ecosystem is. For a product that I worked on - during a decade, the DB system got swapped out 4 times - all driven by customer demand. The app software evolved continuously but the DB was hard changed - with all relevant schema and data migration applied during the upgrade process.
bborud 3y ago
The phrase "to have multiple programs share a database" says a lot about what school of thought one belongs to in terms of architecture. Using the database as the integration point went out of fashion a bit over 20 years ago. And for good reason. It is not a good integration pattern. It makes the implementation the integration interface rather than using a tightly controlled abstraction that can be kept narrow and preserve degrees of freedom for future evolution. And as you allude to: it gets worse because you have to move more application knowledge and logic into the database to make sure applications don't mess it up. In fact, this approach is so bad that Amazon's CEO explicitly forbade it at Amazon (Bezos API Mandate, 2002). How often do you see CEOs, even of tech companies, find an integration pattern so counterproductive and dangerous they announce to the company that they will fire anyone using it? I would say that about 60-70% of projects I've worked on in the last decade have switched databases at least once. One project had support for 5-6 databases and used three different databases in production over a span of 5 years. Adding support for them had fairly low cost (because the internal design made it easy) and it gave us the opportunity to try several things in production, at scale, and then choose what produced the best results. This is a lot better than just choosing something up front and sticking with it because you'll have the data to make an informed choice.