Limitations of using Stretch Database in SQL Server 2016


New feature which was introduced with SQL Server 2016 is Stretch Database which migrates our historical data transparently and securely to the Microsoft Azure cloud. Stretch Database provides some benefits to the users, but also has its own limitations which make it less likely to be used as of now, unless Microsoft comes up with significant improvements. Some of the benefits to decide on using SQL Server 2016 Stretch Database feature are, Provides cost-effective availability for cold data(historical data which is not accessed much, but still available to support user queries from Azure SQL database). Using this feature does not require any changes to the applications, this feature takes care of it internally and transparently. Moving cold or not frequently used data to Azure SQL database will reduce the maintenance efforts on the production data like less times required for backups, indexing statistics updates, etc.

Although this is great feature and very helpful for many organizations, but at this time of SQL Server 2016 RTM release, there are lot of restrictions which make it less likely to be used in many environments, because stretch database cannot be used with many widely used features. Some of the limitations are mentioned below.
– One of the difficult restriction which stops the usage of stretch database is that uniqueness is not enforced for UNIQUE constraints and PRIMARY KEY constraints in the Azure table that contains the migrated data.
– We can’t UPDATE or DELETE rows that have been migrated to Azure SQL database cloud, or on the rows that meet eligible criteria for migration, in a Stretch-enabled table or in a view that includes Stretch-enabled tables.
– We are not allowed to INSERT rows into a Stretch-enabled table over a linked server.
– We cannot create an index for a view that includes Stretch-enabled tables.
– Filters on SQL Server indexes are not propagated to the remote table.
– Some of the Table properties limitations for stretch database include, Tables that have more than 1,023 columns or more than 998 indexes, FileTabless or tables that contain FILESTREAMM data, Tables that are replicated, or that are actively using Change Tracking or Change Data Capture, Memory-optimized tables, etc.

– Data types that are not support in a table to be part of stretch database include, text, ntextt and image
timestampp, sql_variantt, XML, CLR data types including geometry, geographyy, hierarchyidd, and CLR user-defined types
– Column types that are not supported with stretch database include COLUMN_SETt, Computed columns, Constraints,
Default constraints and check constraints, Foreign key constraints that reference the table. In a parent-child relationship (for example, Order and Order_Detail), you can enable Stretch for the child table (Order_Detail) but not for the parent table (Order).
– Indexes which are not supported on stretch database include
Full text indexes, XML indexes, Spatial indexes, Indexed views that reference the table

Local database. The on-premises SQL Server 2016 Release Candidate (RC3) database.
Remote endpoint. The location in Microsoft Azure that contains the database’s remote data.
Local data. Data in a database with Stretch Database enabled that will not be moved to Azure based on the Stretch Database configuration of the tables in the database.
Eligible data. Data in a database with Stretch Database enabled that has not yet been moved, but will be moved to Azure based on the Stretch Database configuration of the tables in the database.
Remote data. Data in a database with Stretch Database enabled that has already been moved to Azure.

Hope this was helpful.

This is applicable for below versions of SQL Server

SQL Server 2016

SQLServerF1 Team
In-Depth Blogs on SQL Server, Information about SQL Server Conferences and Events, Frequently asked questions, SQL Server Trainings


Leave a Reply

Your email address will not be published. Required fields are marked *