- Transaction management
- Its higher limits for storage and table management
Improvement to synchronous replication. Currently Microsoft's Always-On implementation of synchronous replication is not truly synchronous, as it counts the data to be written to the slave node, when it is written to the LDF file, not when it is committed to the actual database. This cause a problem when you are load balancing transactions across synchronous nodes.
I have been using it for over seven years, including 2008 (5/10) and 2012 (6/10) versions. We also have an early release of 2016 (8/10) which I have tested, but it's not in our production environment.
We deploy multiples of these servers now and it is all managed via PowerShell scripts and templates. It does not play nicely with hyper-threading, so we disable this now by default.
If there is flapping of Always-On database node, SQL Server will break the replication to the child nodes, and it requires manual intervention to restart replication.
Currently no as we use our own load balancer to enable us to scale to any level.
A strong knowledge of AD is a must as well as the ability to decipher MSFT blog posts.
We did it in-house.
Depending on how the product is used, it will take about 12 months.
Chose your database based on traffic type and desired functionality not on initial cost.
Take a look at the environment you plan to implement including the application and traffic model. Consider using Azure DB depending on your implementation requirements.