
Ask HN: Have you ever changed your DBMS for a site running in production? - poops
I&#x27;ve worked for places that write straight SQL &amp; places that use an ORM for all the things. I know one benefit of using an ORM is being able to switch to a different DBMS, but I&#x27;m wondering how often that&#x27;s happened. I&#x27;ve been writing web apps for almost 20 years, and have yet to see it happen.<p>I&#x27;m just wondering if anyone has actually done it, and what the reasons were?
======
bnchrch
At my old job we had a lovely django app that acted as the base for multiple
e-commerce sites. It's database layer was initially MySQL but due do
reliability issues, lack of robust admin tools and poor GIS support we made
the move to postgres.

The switch in code was trivial as we were making full use of the Django ORM
and the migration script we created was simple as they were both Relational
DB's. However most of our time was spend testing and creating fail safes as
changing a production DB if done wrong can have dire consequences.

------
YoAdrian
In 16 years, this has only happened once. I had an application running on
64-bit MySQL. We had a legacy app running on 32-bit Oracle. New CTO came along
and made me switch the new app to Oracle since he didn't want to support two
DB platforms. Didn't have ORM or Stored Procs (MySQL didn't support SP at the
time). The SQL wasn't that complicated, but it took me a week to convert the
whole thing. Downgrading to 32-bit DB slowed it down considerably. I left the
company once the update went live.

------
kasey_junk
I've worked in places that have switched dbs many times.

That said, the original reason I encountered for a db abstraction layer (orm
or otherwise) was if you were selling software to be hosted on a clients
stack. The more dbs you could support the better.

------
cameronwatters
I've personally migrated projects from MySQL to PostgreSQL and I'm currently
working with teams that are moving wholesale from MS SQL Server to MySQL.

I tend to abhor full ORMs that require layering deep knowledge of the ORM's
idioms on top of my existing knowledge of SQL and the underlying SQL
implementation. An ORM doesn't magically free me from understanding the actual
implementation and the additional overhead often isn't worth it.

