{"id":8143,"date":"2019-06-19T15:24:45","date_gmt":"2019-06-19T15:24:45","guid":{"rendered":"https:\/\/rax-stg-wp-aws.com\/blogs\/microsoft-sql-server-database-compatibility-levels\/"},"modified":"2026-11-03T19:29:27","modified_gmt":"2026-11-03T19:29:27","slug":"microsoft-sql-server-database-compatibility-levels","status":"publish","type":"blogs","link":"https:\/\/www.rackspace.com\/de\/blogs\/microsoft-sql-server-database-compatibility-levels\/","title":{"rendered":"Microsoft SQL Server database compatibility levels"},"content":{"rendered":"

Introduction<\/strong><\/p>\n

Database compatibility level, one of the database level settings, impacts how a database functions. Each new version of Microsoft\u00a9 , SQL Server\u00a9 introduces many new features, most of which require new keywords and change certain behaviors that existed in earlier versions. To provide maximum backward compatibility, Microsoft enables us to set the compatibility level according to
\nour needs.<\/p>\n

By default, every database inherits the compatibility level of the model database version from which it was created. For example, the compatibility level of a SQL Server 2012 database defaults to 110 unless you change it.<\/p>\n

Compatibility levels after a restore<\/strong><\/p>\n

When you restore a database backup taken on an older version of SQL, the database compatibility level remains the same as it was on the instance from which you took the backup, unless the source compatibility level is lower than the minimum supported level. In that case, the database compatibility level changes to the lowest supported version. For example, if we restore a SQL Server 2005 database backup to SQL Server 2017, then the compatibility level of the restored database would be set to 100 because that is the minimum SQL 2017 level supported.<\/p>\n

Compatibility levels after an upgrade<\/strong><\/p>\n

The compatibility levels of the tempdb, model, msdb, and resource databases are set to the current compatibility level after an upgrade. The master system database retains the compatibility level it had before the upgrade. Determine the compatibility level<\/strong><\/p>\n

To determine the current compatibility level, query the compatibility_level <\/strong>column of sys.databases<\/strong>.<\/p>\n

To change to a different compatibility level, use the `ALTER DATABASE<\/em>` command as shown in the following example:<\/p>\n

    Use Master
\n    Go
\n    ALTER DATABASE <database name>SET COMPATIBILITY_LEVEL = <compatibility-level>;<\/em><\/p>\n

If you prefer, you can use the wizard to change the compatibility level. However, if the database is accessed online by users, you should change the database to single-user mode first.  Then, after you use the wizard to change the level, you should put the database in multi-user mode.<\/p>\n

To change compatibility level with the wizard, right-click database \u2013> property
\n\u2013> options \u2013> Database compatibility level<\/strong> as shown in the following image:<\/p>\n

\"mssql<\/p>\n

Default and supported compatibility levels<\/strong><\/p>\n

The following table shows SQL Server versions with their default compatibility and a list of supported compatibility levels:<\/p>\n

\"mssql<\/p>\n

Image Source<\/em><\/a> <\/p>\n

Database compatibility level and performance<\/strong><\/p>\n

In versions of SQL Server earlier than SQL 2014, database administrators never worried about database compatibility level from a performance perspective. Database compatibility level was mainly used as a mechanism to control whether new features introduced in that version could be used or whether non-supported features were disabled. It was also used to control backward compatibility.<\/p>\n

Now, when you migrate from one version to another, you should do a full regression test to understand the change in  performance. Sometimes, a query performs better with the old compatibility level even after migration. However, in other cases, it could be the opposite, so make sure to do a full regression testing.<\/p>\n

Since SQL Server 2014, any database running at compatibility level 120 or above can make use of the new cardinality estimate<\/em> function. Cardinality estimation is the logic that takes place to determine how SQL Server executes a query,
\nbased on its estimated cost. The estimation is calculated by using input from statistics associated with objects involved in that query. Practically, at a high-level, cardinality estimates are row-count estimates combined with information about the distribution of the values, distinct value counts, and duplicate counts contained in the tables and objects referenced in the query. Getting these estimates wrong can lead to unnecessary disk I\/O due to insufficient memory grants (such as TempDB spills) or to the selection of a serial plan execution over a parallel plan execution, to name a few possibilities. <\/p>\n

\nImpact of changing the compatibility level<\/strong><\/p>\n

Changing the compatibility level tells the database to change its feature set. That is, some features are added, and at the same time, some old features are removed. For example, the FOR BROWSE<\/em> clause is not allowed in INSERT<\/em> and SELECT
\nINTO<\/em> statements at compatibility level 100, and it is allowed but ignored at compatibility level 90. If your application uses this feature, this change might introduce unexpected results.<\/p>\n

When you move a database from a lower to a higher compatibility level, you might expect that you are not able to use the new feature if compatibility is not changed. However, that is not entirely correct. This is only true for the database level feature. You can use instance level features even if you don\u2019t change the compatibility level.<\/p>\n

Conclusion<\/strong><\/p>\n

Database compatibility level defines how SQL Server uses certain features. Specifically, it causes them to act like a given version of SQL Server, which is typically done to provide some level of backward compatibility. Because this is a database property, the compatibility affects only database level features for that specific database.<\/p>\n

If you upgrade a database by either moving it to a server with a higher version or by doing an instance upgrade in place, the compatibility level remains the same as long as that level is supported.<\/p>\n

If the compatibility level is set to SQL 2014 or higher, SQL Server uses the new cardinality estimation feature. If the compatibility level is set to 2012 or lower, the old optimizer is used.
\n <\/p>\n","protected":false},"excerpt":{"rendered":"

Microsoft SQL Server database compatibility levels<\/p>\n","protected":false},"author":2,"featured_media":8145,"menu_order":0,"comment_status":"open","ping_status":"open","template":"","format":"standard","meta":{"content-type":"","nid":"26608","content_type":"blog","created_by":"10130","authored_on":"2024-02-13T16:24:45+00:00","field_article_industries":"","tag_category":"Technical","field_blog_author_text":"by Rackspace Technology Staff","seo_description":"Grasp the concept of database compatibility levels in Microsoft SQL Server. Learn how it impacts database functions and supports backward compatibility.\r\n","field_featured_image":"","insights_image":"\/wp-content\/uploads\/2026\/blog_technical_images\/26608-insights_image-microsoft-technical-blog-1-insights.jpg","field_partners":"","rxt_platforms":"Applications, Microsoft SQL","product":"","publisheddate":"2019-06-19T15:24:45","rxt_solutions":"Cloud Adoption & Migration","opengraph_tag":"","x_tag":"","teaser_flag":"Technical Blog","seo_titile":"Microsoft SQL Server Database Compatibility Levels | Rackspace Technology","field_topics":"","field_slug":"microsoft-sql-server-database-compatibility-levels","footnotes":""},"categories":[178],"tags":[204],"class_list":["post-8143","blogs","type-blogs","status-publish","format-standard","has-post-thumbnail","hentry","category-blog","tag-technical"],"_links":{"self":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/8143","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs"}],"about":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/types\/blogs"}],"author":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/comments?post=8143"}],"version-history":[{"count":3,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/8143\/revisions"}],"predecessor-version":[{"id":9912,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/blogs\/8143\/revisions\/9912"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media\/8145"}],"wp:attachment":[{"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/media?parent=8143"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/categories?post=8143"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.rackspace.com\/de\/wp-json\/wp\/v2\/tags?post=8143"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}