Temporal table considerations and limitations
There are some considerations and limitations to be aware of when working with temporal tables, due to the nature of system-versioning:
A temporal table must have a primary key defined, in order to correlate records between the current table and the history table, and the history table can't have a primary key defined.
SYSTEM_TIMEperiod columns used to record the
ValidTovalues must be defined with a data type of datetime2.
Temporal syntax works on tables or views that are stored locally in the database. With remote objects such as tables on a linked server, or external tables, you can't use the
FORclause or period predicates directly in the query.
If the name of a history table is specified during history table creation, you must specify the schema and table name.
By default, the history table is
If current table is partitioned, the history table is created on default file group because partitioning configuration isn't replicated automatically from the current table to the history table.
Temporal and history tables can't be FileTable and can contain columns of any supported data type other than FILESTREAM, since FileTable and FILESTREAM allow data manipulation outside of SQL Server and thus system versioning can't be guaranteed.
A node or edge table can't be created as or altered to a temporal table.
While temporal tables support blob data types, such as (n)varchar(max), varbinary(max), (n)text, and image, they incur significant storage costs and have performance implications due to their size. As such, when designing your system, care should be taken when using these data types.
History table must be created in the same database as the current table. Temporal querying over linked servers isn't supported.
History table can't have constraints (primary key, foreign key, table or column constraints).
Indexed views aren't supported on top of temporal queries (queries that use
Online option (
WITH (ONLINE = ON) has no effect on
ALTER TABLE ALTER COLUMNin a system-versioned temporal table.
ALTERcolumn isn't performed as an online operation, regardless of which value was specified for the ONLINE option.
UPDATEstatements can't reference the
SYSTEM_TIMEperiod columns. Attempts to insert values directly into these columns are blocked.
TRUNCATE TABLEisn't supported while
Direct modification of the data in a history table isn't permitted.
ON DELETE CASCADEand
ON UPDATE CASCADEaren't permitted on the current table. In other words, when temporal table is referencing table in the foreign key relationship (corresponding to
CASCADEoptions aren't allowed. To work around this limitation, use application logic or after triggers to maintain consistency on delete in primary key table (corresponding to
sys.foreign_key). If primary key table is temporal and referencing table is non-temporal, there's no such limitation.
INSTEAD OFtriggers aren't permitted on either the current or the history table to avoid invalidating the DML logic.
AFTERtriggers are permitted only on the current table. They're blocked on the history table to avoid invalidating the DML logic.
Usage of replication technologies is limited:
Availability groups: Fully supported
Change data capture and change tracking: Supported only on the current table
Snapshot and transactional replication: Only supported for a single publisher without temporal being enabled, and one subscriber with temporal enabled. Use of multiple subscribers isn't supported as this may lead to inconsistent temporal data due to dependency on the local system clock. In this case, the publisher is used for an OLTP workload while subscriber serves for offloading reporting (including
AS OFquerying). When the distribution agent starts, it opens a transaction that is held open until distribution agent stops.
ValidToare populated to the begin time of the first transaction that distribution agent starts. It may be preferable to run the distribution agent on a schedule rather than the default behavior of running it continuously, if having
ValidTopopulated with a time that is close to the current system time is important to your application or organization. For more information, see Temporal table usage scenarios.
Merge replication: Not supported for temporal tables
Regular queries only affect data in the current table. To query data in the history table, you must use temporal queries. For more information, see Querying data in a system-versioned temporal table.
An optimal indexing strategy includes a clustered columns store index and/or a B-tree rowstore index on the current table and a clustered columnstore index on the history table for optimal storage size and performance. If you create/use your own history table, we strongly recommend that you create this type of index consisting of period columns starting with the end of period column, to speed up temporal querying and speed up the queries that are part of the data consistency check. The default history table has a clustered rowstore index created for you based on the period columns (end, start). At a minimum, a nonclustered rowstore index is recommended.
The following objects/properties aren't replicated from the current to the history table when the history table is created:
- Period definition
- Identity definition
- Check constraints
- Partitioning configuration
- Row-level security predicates
A history table can't be configured as current table in a chain of history tables.
SQL Server documentation uses the term B-tree generally in reference to indexes. In rowstore indexes, SQL Server implements a B+ tree. This does not apply to columnstore indexes or in-memory data stores. For more information, see the SQL Server and Azure SQL index architecture and design guide.
- Temporal Tables
- Getting Started with System-Versioned Temporal Tables
- Temporal Table System Consistency Checks
- Partitioning with Temporal Tables
- Temporal Table Security
- Manage Retention of Historical Data in System-Versioned Temporal Tables
- System-Versioned Temporal Tables with Memory-Optimized Tables
- Temporal Table Metadata Views and Functions