In the last year, I have presented quite a bit on SQL Server 2017 running on Linux – both publicly, and for customers.
In almost every instance, I have been asked about what SQL Server features are supported while running on Linux, which is certainly important to understand before you go down the path of implementation. While this is generally well documented here, I always like to show the table below and talk a bit about the limitations, and discuss how they may affect adoption for each specific use case. A lot of the limitations are understandable, especially given the v1 nature of the product, and the complete overhaul that was needed to make it work. I think another factor might be an overall lack of support of features needed to support some of the functionality in the open-source implementations of the Windows equivalent services, or an overall lack of a standard way to do certain things that are well defined in Windows.
However, there’s some interesting things in here that really need to be there in the very near future.
This table below is accurate as of 4/15/2018, and can change at any time.
This is just a compilation from the link above to Microsoft.com
Database Engine:
A lot of this is understandable, but I was really surprised at the lack of transactional replication support. This has been a core feature of the product for over 20 years. Depending on the exact need, there could be plenty of ways to accomplish the task without it, but there’s a lot of mission-critical mouse-traps out there that depend on this feature. Merge Replication is quite a bit newer, but I have come across its use at many customers it with various levels of success. Personally, if the environment requires transactional or merge replication, I’m not seeing the value in re-tooling an entire solution just to migrate. There’s got to be some other pressing reason. Like stability and scalability.
Also surprising is Polybase and Stretch DB. While I have not run across a lot of either, I do have customers using them. Also, given that they’re newer features, and were fairly large part of the marketing message behind SQL Server 2016, the exclusion does seem a bit strange. Also strange considering there’s a good chance that shops looking to use SQL Server on Linux may already have an investment in other Big Data tech they’d want to integrate with – exactly what Polybase is for. Seems slightly backwards, IMO.
I am not surprised by the lack of Filetable support. Given the feature that it provides, I would image there’s a lot of dependencies on Windows SMB functionality that would probably have to be ported as well. I would expect to see this feature supported at some point in the future, but probably after there’s some specific support added to SAMBA or another specific SMB/CIFS package, or Microsoft rolls their own, and the *NIX world that has to support Windows protocols will rejoice much. And then we’d finally get Data Domain CIFS support working like a first-class citizen. You know what? Microsoft – PLEASE do that, and then open-source it.
You’d make the world a better place.
Lack of UNSAFE and EXTERNAL_ACCESS CLR assemblies will immediately prevent many vendors from supporting SQL Server on Linux.
SQL Server Agent:
Most surprising here to me is Alerts. I consider Agent Alerts on certain very specific severity messages (16-25, and 823-825) to be absolutely critical to monitoring a production server. I typically will not release an instance to production without these Agent Alerts in place. There’s other ways to implement this, using monitoring tools, custom scripts, etc – but this is a very critical feature that needs to be added ASAP. If I had to guess, this is possibly due to guaranteeing there’s a predictable, standard, and reliable way to send mail directly from the Linux host in place. However, that’s mostly just as easy as requiring their preferred SMTP transport as an dependency, or rolling their own in to the product.
Lack of CDC support makes sense, given the lack of a Log Reader Agent, but I see it as a significant hole. We do get System-Versioned Temporal Tables, so it’s possible some of the gap can be covered by that, depending on the specific implementation.
Managed Backups is something that will probably affect a smaller subset of my potential customers, as I’m not seeing it much out in the wild.
High Availability:
To me, the lack of mirroring is really no big loss. Microsoft has been threatening us with the big “D” on that feature for a while now, and frankly I am happy to see it gone, now that we’ve got Basic Availability Groups included with Standard (which would be a lot more awesome if we could actually run DBCC CheckDB on the replica…). I totally understand that some vendors out there still will not support Availability Groups for whatever reason, but this gap is closing every day.
Security:
OK – Lack of 3rd party AD tools is a pretty big hole here. In my career, I have done quite a bit with Identity and Access Management (IAM) in mixed environments. Probably the best tool out there for this is Centrify, which is probably why it’s specifically called out, but there’s several others. A lot of my customers are looking for ways to integrate their identities, and even MFA/2FA across their multi-vendor, multi-OS landscape, and not playing nice with the tools that do this is not the way you make friends.
This alone may prevent adoption in some large *NIX shops. Missing AD Auth for Linked Servers is also a pretty large deal for a lot of my customers. The good news is that we DO get TDE, Always Encrypted, Dynamic Data Masking, and Row-Level Security. So there’s that.
Services:
Lots of interesting exclusions here.
SQL Server Browser is an interesting one, as its very useful in multi-instance environments. At least ones that don’t require ports on connection strings.
StreamInsight is not something I really see out there, and those customers that have talked about it have found a better fit with cloud technologies. So, I would not think it would affect my customers. Analysis Services, on the other hand, may be a big for a lot of shops that want a single server implementation, however I am personally seeing a trend of migration from AS to other technologies, including cloud-based ones. Plus, there’s nothing stopping you from housing AS on a windows host, and still using the Linux SQL Server as a data source.
I go back and forth on Reporting Services. A lot of my customers use it, but almost all are looking to migrate to Power BI or some other similar offering. The largest gap I see is with packaged applications. Also, as before – nothing stopping someone from having the RS tier in a Windows VM, and use the Linux SQL Server as a data source Well, except licensing – so consider that as you’re planning your solution. I actually feel exactly the same about Master Data Services and Data Quality Services.
Essentially, for any of the excluded services, those that need it can still implement those tiers on Windows without too much hassle.
DBADave.com 