I’m getting an increasing number of requests these days that say:
“We’re considering migrating our application from SQL Server to a cheaper, easier-to-scale database. Can you help?”
Well, kinda: why are you doing it?
If you’re doing it to get easier scalability, we start by taking a step back and looking at the performance problems in the current setup. Usually, I get these kinds of calls from teams of developers that don’t have a full time DBA. They’ve built a software-as-a-service application, and they’re hitting performance issues. The simple fixes are:
- Measure the SQL Server’s current bottleneck with wait stats (like with sp_BlitzFirst @SinceStartup = 1)
- Find the queries causing those bottlenecks (like with sp_BlitzCache @SortOrder = ‘reads’)
- Remove the bottlenecks by tuning indexes, queries, SQL Server config settings, or hardware
If you don’t have a full time database administrator, then it’s easy to implement a round of quick fixes in just a few days that take care of the low-hanging fruit. This usually buys the company a year’s worth of runway time, at which point they can either knock out another round of low-hanging fruit, or reconsider the database back end decisions.
If you want lower SQL Server licensing costs, then we take a step back and look at how you’re buying SQL Server today. I usually hear this goal from companies renting their licensing from their hosting provider (like Rackspace or AWS), in which case we’ve got a few options:
- Can we performance tune the database to run on a smaller instance size?
- Can we drop from Enterprise Edition to Standard Edition?
- Can we move non-relational data out of the database? (Like full text search, XML/JSON storage)
- Can we implement a free/cheap caching layer like hosted Redis?
Those projects are usually way cheaper and faster than trying to rewrite the entire application’s back end. That’s what these change-databases projects usually involve – as soon as you take even a cursory look at the database queries, they’re written in a way that ties them to a specific database platform.
Don’t get me wrong – I’m not saying SQL Server is the best answer for every app.
But I *am* saying that rewriting the entire app almost never is.
Erik says: If you use common table expressions, re-writing your code for MySQL will be fun. By fun I mean “use Postgres instead”.