What version of sql should i download

The Enterprise Edition and the Developer editions have full functionality. However, the Developer edition is not for production environments as the name indicates, it is for development purposes. If you only need a small database for development to store data in tables, the SQL Express will be enough. If you do not have too much disk space, the SQL Express will be the best option.

The Developer edition has the same functionality as the enterprise edition, so, it will accomplish all your needs. In order to check the difference between both editions, check the supported features of SQL Server:. For testing, QA, development and learning purposes, I would use Docker. And for the production environment, it depends on what you have.

It has a lot of support and it is working fine for decades. On the other hand, SQL Server for Linux is newer, and it may have more errors and less documentation, forums and people to help you. The SQL Server download process also implies to choose the right version. SQL Server is not released yet, so I would only recommend using it for testing purposes and to know the new functionality in testing environments.

The best choice would be SQL Server which is a robust, stable version. For more information about the features of each version, refer to the following links:. If you are nostalgic about the history of SQL Server and the different versions, I would suggest going through the below link:.

If you are learning SQL Server, this sample data is very useful to test queries, test features and check the documentation. Information Title. URL Name. Which one should I use? SQL Server has different licensing models you can select from that would best suit your organization.

Click here to open a support case. Article Suggestions? Click here to email Support Knowledge. Hi Timothy King, No need to fear about end of support. As a Microsoft SQL Server DBA , we raised a support ticket to Microsoft support team for a major bug in non clustered column store index in version SP2 due to our internal security policies restrictions we are unable to bring the support team to diagnose our server.

Because the team will install some diagnostic software and collect logs from our server, as per the policy we have so many restrictions and unable to proceed further, in that case we are unable to utilize the support. Better to use a stable version of SQL server, I believe or consider as a stable versions, to my experience new versions of SQL server are concentrated in cross platform technologies for analytics workload, most of the existing queries running well in are running with degraded performance due to the latest cardinality estimation and optimizer enhancements, Even Microsoft accepted this as a bug and provide workaround like this, enable legacy cardinality estimation on, use query hint for the specific query blocks, change sql server compatibility to something like this.

But one thing we need to consider in future if there is very limited scope to bring other data source data for processing in your environment means we can run with older version of SQL server. Existing features requires lot of improvements but Microsoft is not looking such things and releasing versions like a movie.

If i am explains multiple items then people may thing i am surfing from internet and write those but not like that these are all our real time issues we faced. Please stick with your stable SQL server version for your continuous application support without any escalations. A year later, is the your advise still to stay with SQL? For example, how many people actually know what the permanent changes to TempDB in the form of making TF functionality no longer optional for TempDB are?

All 8 files automatically tried to grow to 25GB. The only way to recover that space is to rebuild the related heap or index. The only way to overcome the problem without changing code is to use TF We have SSRS reports too.

Also, do you recommend using compatibility mode? No much to gain but can upgrade by changing the compat mode. Love to hear your opinion on this. There are no new features we wish to take advantage of at this time , just want to push out the time to the next upgrade , hot diggity!

I am the DBA so would like to go , but dev feels we should go to It reminds me of the RTM for , which was just awful. Thanks for your post, Brent. How about upgrade to from where you are. Consider it base camp for the next upgrade. You will be in striking distance of the next upgrade and can hang with for years if you want. Looking for ammunition to push back against management who hears we are running on while the calendar will soon say Typically, change equals risk.

It continues to work, only more efficiently. Normally, the reverse has been true every time a new version comes out. I used to wait for SP1 but , , and now changed all that. If I can afford to do so, I try to quietly lag behind by at lease 1 version. If you remember all the horror in until they finally fixed most of their regression mistakes in SP3, you know why I take such a position.

I had a very good experience with the hole thing, for example, Always-on, for example is great, very powerfull tech, I am also involved in RDBMS radical migration, only a few, from Oracle to Sql-Server, due to Management decisions for lowering license costs and this also were a success.

And if someone is only using Web Edition features, how does that affect your recommendation? A noticeable change between and is the capabilities of graph databases. You can directed graphs in using edge constraints and it protects against deleting nodes with edges, things not in Great Article! We have some Databases in and , and were in the final phase of testing with SS, and in one particular database we use a lot of UDF and TVF, the performance in these database is in average 1.

Already tried every configuration possible in the server, disabling inling in some functions helped, but most of the functions are lot inlineable! Probably will Go to SS! The way Unicode characters are hashed in sql until SQL Server was not consistent with hash made in Python or other languages. So if you hashed your data vault keys with sql server and you want to integrate that with data stored outside of sql say in a datalake, and your hashing values had Danish letters for instance, then the same key will have two different hash values.

Hello, We have now 11 CUs for and almost 2 years sice its release. What is the big blocker with SQL to go to production? Is there something specific that is dangerous at this moment? Please consider that is almost out of mainstream support and only and will have full support. Hello, I had the feeling that you do not recommend it at all, but it seems I am not entirely right after I read carefully: In our case we have all the issues that SQL suppose to fix.

Even we are facing last-page contention on some tables. I hope to have more benefits than negatives.

We aim to go to Prod Q4 If anyone else does the migration, it would sure be nice if you good folks would reply on this thread with the same vigor and detail to let the rest of us know how things worked out. I do hate supporting multiple SQL Server versions. Its difficult to implement new features, then do a separate cut for older versions.

It would be nice if a patch to older versions would allow ignoring syntax specific to new versions when possible. A patched build would recognize this as a valid syntax, and then ignore it. I still doubt. Cylance especially has been particularly problematic, but have had issues with cisco, defender, mcafee and to a lesser degree fire eye. Exclusions lists that used to work, have needed to be added to, in order stop what appears to be heuristics engines from scanning activities they have seen on a particular server literally hundreds of thousands of times.

Have had something like installing a CU cause a failover cluster or availability group to fall apart, sometimes after OS reboot come back and then not be an issue again, but also sometimes having to uninstall CU, turn off the AV and reinstall CU, to make it work again. We receive SQL backups from them and restore to a SQL Server in our data center, which would mean we need to upgrade our servers to as well. Generally speaking, do the same concerns with SQL Server exist if you keep databases in a lower compatibility mode say or ?

Mark — go through the list of concerns on , and think about which ones happen regardless of compatibility level. Your email address will not be published. Don't subscribe All Replies to my comments Notify me of followup comments via e-mail. You can also subscribe without commenting.

Post Comment. Want to advertise here and reach my savvy readers? My annual Black Friday sale is on now! Last Updated June 11, Brent Ozar. You use log shipping as a reporting tool, and you have tricky permissions requirements because they added new server-level roles that make this easier.

You still have to put in time to find the queries that are gonna get slower, and figure out how to mitigate those. This meant you could write one version of your application that worked at both your small clients on Standard, and your big clients on Enterprise.

This grid has a great comparison of what changed with columnstore over the years. Remember, there are no more Service Packs, just Cumulative Updates. You have a zero-RPO goal and financial risks — because added a new minimum commit replica setting on AGs that will let you guarantee commits were received by multiple replicas You want easier future upgrades — because starting with , you can have a Distributed Availability Group with different versions of SQL Server in it.

You need high performance columnstore queries — because we got a lot of cool stuff for batch mode execution plans. Some of the clustering bugs have really made my eyebrows raise. That makes me pretty uncomfortable for mission-critical production environments. You heavily rely on user-defined functions — because can dramatically speed those up , although you need to do a lot of testing there, and be aware that Microsoft has walked back a lot of the improvements.