I just recently read this blog post by Rob Sullivan about why he prefers Postgres over SQL Server. Honestly, I’m not very impressed. 3 of his 10 reasons aren’t really reasons; yes, you don’t get these things if you aren’t using Enterprise Edition, but here’s the thing: if you’re running a business and decide that SQL Server is the right product for you, go with Enterprise Edition. Yes, it’s going to cost more money, but the difference isn’t really that much if you’ve already decided to go down the paid RDBMS route. Not being able to install SQL Server on non-Windows machines is a bit of a letdown, but again, if that’s one of your top reasons, it’s not really much of a reason for most enterprises, as they’re already using Windows servers somewhere.
Regarding arrays, it’s true that SQL Server doesn’t have them. There are better and worse alternatives, but aside from parameter input, if you’re using arrays, you’re thinking procedurally and that’s doing it wrong.
Now, I’ll say that I like Postgres a lot—it’s my second-favorite relational platform, and I use it on my own corporate site. And way up on my list of reasons to use Postgres over SQL Server is its greater support for windowing functions. But I decided to try to come up with 10 reasons to use SQL Server over Postgres, just to see if I can do it. Here goes:
- SQL Server Integration Services. You get a fully-featured, high-quality ETL tool out of the box.
- SQL Server Analysis Services. You get probably the most complete implementation of the Kimball method for data warehousing out of the box.
- SQL Server Reporting Services. You get a mid-range, pretty decent reporting solution out of the box.
- SQL Server Management Studio. This is an outstanding tool. Yeah, it’s kind of a mish-mash of developer tool plus management tool, but it works quite well.
- Always On Availability Groups. You get failover and read-only replicas out of the box. There are high availability options available for Postgres, but I’m not familiar enough with them to know how well they work; I am familiar enough with Always On to know that it does a nice job.
- Service Broker. This is a built-in message queue system which SQL Server uses internally. It’s true that it won’t scale to the extent of Rabbit or another in-memory queuing system, but for relatively low-frequency message pushing, it works well out of the box.
- SQL Server Agent. You get a good scheduling tool out of the box. Yeah, there are better schedulers out there, but it does the job pretty well.
- Extended Events and wait stats. Managing a SQL Server instance is relatively easy due to these two things. Extended Events let you monitor system health and wait stats tell you which resources your queries are waiting for (be they locks, latches, CPU, disk, memory, network, or even because somebody selected 20 million rows and their client is taking its sweet time reading in all of the data). I have no idea if these concepts exist in Postgres, but they’re out of the box in SQL Server, and 2012 even has a GUI for Extended Events.
- Policy-Based Management. This is another management tool, but one which can act as preventative maintenance as well. You set up policies (such as how procedures should be named) and can apply those pro-actively or use them to scan a system for problems.
- Resource Governor. SQL Server 2014 version should make this a must-do for enterprises, because then you’ll be able to throttle and cap I/O as well as CPU. This way, your business analysts won’t take down your OLTP server by running crazy queries on it.
- Community. This is my ace in the hole. SQL Server has a huge support community, with blogs, user groups (virtual and in-person), ridiculous numbers of videos and tutorials from outstanding DBAs, regular free conferences, big conferences, and even newsletters.
SQL Server isn’t for all businesses, but there are some powerful reasons to adopt it as well as Postgres.