Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

SQL Server 2012 introduced the concept of "contained" databases, where everything (well, mostly everything) the database needs is contained within the database itself. This offers big advantages when moving databases between servers. I would like to know, then, if this should be my default strategy when designing a new database.

MSDN lists several disadvantages to contained databases, and the big ones are a lack of support for change tracking and replication. Are there others? If I'm not going to use these features, is there any reason not to use contained databases?

share|improve this question

migrated from stackoverflow.com Aug 1 '12 at 18:47

This question came from our site for professional and enthusiast programmers.

1 Answer 1

up vote 10 down vote accepted

The primary purpose of contained databases is to make it easier to port your database to a new server without a lot of scaffolding around it. With that in mind, I'll treat a few potential issues that will make this migration more difficult - and most revolve around the fact that contained databases are only partially contained in SQL Server 2012 (containment is not actually enforced).

Connection strings

Connection strings to a contained database must explicitly specify the database in the connection string. You can no longer rely on the login's default database to establish a connection; if you don't specify a database, SQL Server is not going to step through all the contained databases and try to find any database where your credentials may match.

Cross-db queries

Even if you create the same user with the same password in two different contained databases on the same server, your application will not be able to perform cross-database queries. The usernames and passwords may be the same, but they're not the same user. The reason for this? If you have contained databases on a hosted server, you shouldn't be prevented from having the same contained user as someone else who happens to be using the same hosted server. When full containment arrives (likely in the version after SQL Server 2012), cross-database queries will absolutely be prohibited anyway. I highly, highly, highly recommend that you don't create server-level logins with the same name as contained database users, and try to avoid creating the same contained user name in multiple contained databases.


Most 3- and 4-part names are easy to identify, and appear in a DMV. However if you create a synonym that points to a 3- or 4-part name, these do not show up in the DMV. So if you make heavy use of synonyms, it is possible that you will miss some external dependencies, and this can cause problems at the point where you migrate the database to a different server. I complained about this issue, but it was closed as "by design." (Note that the DMV will also miss 3- and 4-part names that are constructed via dynamic SQL.)

Password policy

If you have created a contained database user on a system without a password policy in place, you may find it hard to create the same user on a different system that does have a password policy in place. This is because the CREATE USER syntax does not support bypassing the password policy. I filed a bug about this problem, and it remains open. And it seems strange to me that on a system with a password policy in place, you can create a server-level login that easily bypasses the policy, but you can't create a database user that does so - even though this user is inherently less of a security risk.


Since we can no longer rely on the collation of tempdb, you may need to change any code that currently uses explicit collation or DATABASE_DEFAULT to use CATALOG_DEFAULT instead. See this BOL article for some potential issues.


If you connect to a contained database as a contained user, SSMS will not fully support IntelliSense. You'll get basic underlining for syntax errors, but no auto-complete lists or tooltips and all the fun stuff. I filed a bug about this issue, and it remains open.

SQL Server Data Tools

If you are planning to use SSDT for database development, there currently isn't full support for contained databases. Which really just means that building the project won't fail if you use some feature or syntax that breaks containment, since SSDT currently doesn't know what containment is and what might break it.


When running an ALTER DATABASE command from within the context of a contained database, rRather than ALTER DATABASE foo you will need to use ALTER DATABASE CURRENT - this is so that if the database is moved, renamed, etc. these commands don't need to know anything about their external context or reference.

A few others

Some things you probably shouldn't still be using but nonetheless should be mentioned in the list of things that aren't supported or are deprecated and shouldn't be used in contained databases:

  • numbered procedures
  • temporary procedures
  • collation changes in bound objects
  • change data capture
  • change tracking
  • replication

That all said, these aren't necessarily disadvantages to using contained databases, they're just issues you should be aware of and aren't all explicitly disclosed in the official documentation.

You'll also need to be sure that if a contained database is going to be migrated, or is part of an availability group or is being mirrored, that all potential destination servers have the sp_configure option contained database authentication set to 1.

You may find this blog post useful, as well as this one, even though they pre-date RTM.

share|improve this answer
Do you know why temporary procedures aren't allowed? –  Jon Seigel Aug 2 '12 at 2:54
@JonSeigel they're still allowed under partial containment, but they breach containment (meaning there is no way to validate what entities the procedure accesses, since it's metadata and definition are stored elsewhere) so not recommended. From msdn.microsoft.com/en-us/library/ff929071.aspx#Limitations: Temporary stored procedures are currently permitted. Because temporary stored procedures breach containment, they are not expected to be supported in future versions of contained database. –  Aaron Bertrand Aug 2 '12 at 3:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.