4 ms·

I’ve been through plenty of cases where companies successfully swap out databases exactly as you described - a document storage for an Rdbms or vice-versa. The

by herval 6y ago

I’ve been through plenty of cases where companies successfully swap out databases exactly as you described - a document storage for an Rdbms or vice-versa. The bird social network is an example where the db was so well abstracted, they managed to swap these out with no need to rewrite any application code. So does Facebook, for instance. Slack is a clear example of what the complete lack of forethought on this leads to. (Disclaimer: I’m familiar with all 3, but obviously can’t talk details - there’s plenty of public posts on these cases, though) FWIW, every single db abstraction I’ve ever witnessed was worth it - if only so that one could run tests in a sqlite and run prod in something else, or as a way to contain vendor lockin in the code (I’ve seen projects successfully migrate from a plsql-heavy system to mysql because the code was well segregated, and I worked at a startup that literally imploded bc the database was metastasized all over the place) Anyway, as I put it, abstracting data storage is a no-brainer for me, and it saved my skin every single time. I don’t expect to convince anyone here to go do it. :-)

ivan_gammel 6y ago
>>the db was so well abstracted, they managed to swap these out with no need to rewrite any application code What were the reasons for the swap and what were the outcomes of it besides that it actually happened? Costs, performance, scalability etc? I think hardly anyone would argue that those transitions are impossible, because they are indeed possible. The main question is usually if your abstraction can leverage the benefits of underlying implementation or it is just a common denominator. I can imagine a clever technical strategy in a startup, foreseeing future growth and starting with a simple DB before moving to a more complex in maintenance but scalable solution. This may work. Often it doesn't.
- herval 6y ago
  Varies from project to project of course, but it’s never “just because”. If you’re swapping dbs without reasonable expectations to improve SOMETHING, it is indeed a waste of time (one that I also fought against in my career many times - been through many, many “let’s adopt MongoDB bc it’s hot” cases)
geofft 6y ago
I think that's changed my mind a little bit on this, thanks! I'm mostly surprised they were able to get the abstraction right in advance - did they have an idea of what they might move to? Or did they change the abstraction as they went, but the abstraction layer made it easier to find what parts of the code needed changing, or something? How do you avoid the issue where SQLite doesn't support all the things your real DB supports? (i.e., why is it worth running tests on SQLite as opposed to a local instance of the same DB software?) I'll read some of these public posts....
- herval 6y ago
  The only case I witnessed where the interface remained untouched, even as we went from an rdmbs backend to kvo and back again, was Twitter. You can argue the reason is the data model being simple, which makes sense. Everywhere else, it was different degrees of “pain”. I don’t think there’s a silver bullet, and I don’t think avoiding a potential future rewrite at all cost are worthwhile goals. WRT sqlite, the obvious advantage is test setup doesn’t require any local infra, and it forces your system to NOT use vendor-specific features. That school of design is essential for places that want to avoid lockin for whatever reason. This isn’t possible in every case - some companies have a great DBA team, for instance, or strong specialization around a specific db (cough Oracle shops cough), so obviously that flexibility wouldn’t be advantageous. As everything else in our industry, it depends :)

by herval 6y ago

ivan_gammel 6y ago

>>the db was so well abstracted, they managed to swap these out with no need to rewrite any application code What were the reasons for the swap and what were the outcomes of it besides that it actually happened? Costs, performance, scalability etc? I think hardly anyone would argue that those transitions are impossible, because they are indeed possible. The main question is usually if your abstraction can leverage the benefits of underlying implementation or it is just a common denominator. I can imagine a clever technical strategy in a startup, foreseeing future growth and starting with a simple DB before moving to a more complex in maintenance but scalable solution. This may work. Often it doesn't.

herval 6y ago
Varies from project to project of course, but it’s never “just because”. If you’re swapping dbs without reasonable expectations to improve SOMETHING, it is indeed a waste of time (one that I also fought against in my career many times - been through many, many “let’s adopt MongoDB bc it’s hot” cases)

geofft 6y ago

I think that's changed my mind a little bit on this, thanks! I'm mostly surprised they were able to get the abstraction right in advance - did they have an idea of what they might move to? Or did they change the abstraction as they went, but the abstraction layer made it easier to find what parts of the code needed changing, or something? How do you avoid the issue where SQLite doesn't support all the things your real DB supports? (i.e., why is it worth running tests on SQLite as opposed to a local instance of the same DB software?) I'll read some of these public posts....

herval 6y ago
The only case I witnessed where the interface remained untouched, even as we went from an rdmbs backend to kvo and back again, was Twitter. You can argue the reason is the data model being simple, which makes sense. Everywhere else, it was different degrees of “pain”. I don’t think there’s a silver bullet, and I don’t think avoiding a potential future rewrite at all cost are worthwhile goals. WRT sqlite, the obvious advantage is test setup doesn’t require any local infra, and it forces your system to NOT use vendor-specific features. That school of design is essential for places that want to avoid lockin for whatever reason. This isn’t possible in every case - some companies have a great DBA team, for instance, or strong specialization around a specific db (cough Oracle shops cough), so obviously that flexibility wouldn’t be advantageous. As everything else in our industry, it depends :)