Although I'm sure there are plenty of fine things in SQL Server 2019, I must take it on trust because few are likely to affect my work as a database developer. I feel sure that DBAs will manage to work themselves into excitement but, unless I've missed something, as a developer I must content myself with the bone of Scalar UDF in-lining. This doesn't allow you to do more with a scalar UDF. It just runs faster. I'd now rather like it to do more. Please don't think I'm sulking; I just wish that some of the existing, but undistinguished, features would get some of the attention.

This isn't a release like 2012 or 2017, where, after years of neglect, database developers got some love. In fact, it was as much as we could do to keep up. We got the full Windowing functions after all, though it was some time after other leading RDBMS got them. We loved STRING_AGG (2017). We thought OPENJSON (2016) was cool, even if we only use it as a way of passing 'mutable' lists, or tables, between routines. It was handy to be able to define indexes within the table's CREATE statement. TRY_PARSE solved a lot of problems.

There were some damp squibs, though. STRING_ESCAPE could only do JSON, but not XML or HTML. STRING_SPLIT (2016) could only cope with single-character separators. TRANSLATE (2017), a curious single-purpose function. This isn’t helped by the documentation which puzzlingly, says 'TRANSLATE does not, however, replace a character more than once', though it seems to in practice.

FORMAT is fine for short runs, if you really want to get involved with presentation stuff but is slow with large result sets. CONCAT_WS (2017) allows you to do things that are already easy, such as joining column values into strings. One could go on and on, but the point is that currently in SQL Server 2019, the energy isn't going into keeping SQL Server in parity with, say, PostgreSQL as a developer tool.

Nowadays, SQL Server developers are increasingly having to tough it out in an industry that has plenty of alternative development stacks. Sometimes a team can appear to make much more rapid initial progress with a MEAN (MongoDB, Express.js, AngularJS and Node.js.) stack or even the old LAMP (Linux, Apache, MySQL/MongoDB and PHP) stack, while on SQL Server (the M could stand for MSSQL these days, after all), we still, for example, wrestle with the basics of producing the JSON documents that application developers need, with such things as arrays.

The industry is changing rapidly, and SQL Server needs to make sure that it is there in the forefront, actively supporting all the changing architectures and data document formats that, like it or not, are being increasingly adopted. They need to give developers the warm feeling that Microsoft are continuing to think carefully how they can support them and proving to us that SQL Server is still the obvious choice, by providing all the extra features we need.