Skip navigation
SQL Server Needs to Step Up Its Game

SQL Server Needs to Step Up Its Game

First, congratulations to the SQL Server team for helping make SQL Server the #1 most-used database engine on the planet. They've done a fantastic job of delivering a fantastic product, pleasing customers, and clawing their way to the top of a very competitive market. Unfortunately, it looks like they might have started letting some of their success and triumph go to their heads.

What Made SQL Server Strong

Having been in the trenches with SQL Server for over a decade, at which point I've hands-down hitched my career to SQL Server's success, I've got my own ideas about what allowed it to be such a strong offering and climb its way to the top:

Related: "The SQL Server Community: A Welcoming Place for Newbies"

Approachability. A big win for SQL Server has always been a question of how easy it's been to pick up and learn, especially in comparison to other RDBMses out there. As I've argued in the past, I think Microsoft products, especially SQL Server, find themselves in a very open and generous community of users. Microsoft has also done a fantastic job of making training, documentation, and lots of support and different learning options available as part of their bid to take over the world with SQL Server.

Price. In addition to a lower sticker price compared to many competitive offerings, I'd also argue that SQL Server's ability to manage itself fairly well and without the need of a full-time DBA on many servers with the right kinds of workloads makes it a huge win.

Developer Support. Stored procedures have always been a big win for SQL Server users, and Microsoft's support for ODBC and OLEDB have made it very accessible from a wide variety of development platforms. I'd also argue that the great interaction between SQL Server and .NET are a big part of what's helped make SQL Server so successful and ubiquitous.

Business Intelligence. Another huge strength that SQL Server brought to the table was its mission of democratizing business intelligence (BI). Although that's not too big of a concern or focus for lots of developers, there's simply no doubt that a key part of SQL Server's success is how a single SQL Server license provides substantial value in terms of enabling a strong OLTP engine, providing OLAP/data-warehousing capabilities, and even providing the ETL (SSIS) and reporting (SSRS) tools to go with everything.

The New Face of SQL Server

With recent versions of SQL Server, I think it's pretty easy to see that Microsoft has not slacked off on adding new BI engine features and capabilities (though I've seen decent amounts of grumbling about failure in the tooling and reporting space). Likewise, I'd argue that SQL Server's approachability has never been better—with things like SQLSaturday, the Twitter #SQLHelp hashtag, a veritable cornucopia of SQL Server related blogs, free training, and a host of other goodies.

Related: "SQL Server 2012: Top New Features for .NET Developers"

From a developer support perspective, the last big or major innovation we saw was the introduction of the CLR in SQL Server 2005. Otherwise, we've seen some incremental improvements, but nothing huge. And, I don't count things such as RCSI or even SQL Server 2014's upcoming Hekaton support. Those are nice features that do benefit developers, but only in the sense that they increase throughput and scalability.

Finally, pricing has become a serious sore spot. And I'm not talking about SQL Server 2012's switch from licensing sockets to licensing cores. In my mind, that decision was totally fair and acceptable as sockets today are simply much more powerful than they've ever been in the past, and SQL Server has always been licensed on the notion of "pay for what you use." Instead, what I'm complaining about and what I find particularly galling is how SQL Server 2008 R2 and later releases seem to be based much more on lock-in, price-gouging, and forced-upgrades than they do about the fairness of licensing that has helped propel SQL Server to the top of the pig pile. Specifically, I'm making reference to the fact that SQL Server 2008 R2 and later versions artificially limit Standard Edition workloads to 64GB of RAM. Given that DDR4 is now looming on the horizon, the ridiculousness of this artificial constraint will become fully apparent when we potentially start seeing single DIMMs with 64GB of RAM on them towards the end of SQL Server 2014's end of lifecycle, which will be within a few years.

PostgreSQL: Lean, Mean, Scrappy, and Gorgeous to my Inner-Developer

SQL Server has helped me pay the mortgage for over a decade—to the point where I never thought I'd even think about straying. But Microsoft's recent licensing shenanigans with Standard Edition and dearth of developer 'love' with recent versions of SQL Server have really caused my eye to wander.

On one hand, I'm now to the point where at least once a week, I just can't believe that SQL Server doesn't support JSON. (Seriously SQL Server? XML? XML was cool and hip back in 1999—it got lame years ago.) On the other hand, PostgreSQL, which is totally and completely free, not only has JSON support, but also has JSON support to such a level that indexing JSON data is possible. But that's only the tip of the iceberg—PostgreSQL has a huge number of very cool features and capabilities that developers would love. In fact, it's now really just a question of time before I take PostgreSQL for a spin, especially since it'll be trivial to host.

And, no, I'm not quite ready to jump ship yet, but the point is that SQL Server seems to have gotten to a point where it acts like it can rest on its laurels. PostgreSQL isn't perfect or without flaws. But it's made insane headway and progress in the past few years, is quite capable, insanely developer-friendly, and seems scrappy and hungry to take on more market share. As such, I can only hope that SQL Server steps up its own game, provides some additional developer love and support, and stops forgetting how it got to be where it is today.

Hide comments


  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.