Ask HN: Have you ever changed your DBMS for a site running in production?

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.

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.

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.

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.