A system-versioned temporal table is implemented in SQL Server 2017 as a pair of tables: the current table containing the actual data, and the history table where only historical entries are stored. There are many limitations for both current and history tables. Here are limitations and considerations that you must take into account for the current table of a system-versioned temporal table:

• It must have a primary key defined
• It must have one PERIOD FOR SYSTEM_TIME defined with two DATETIME2 columns
• Cannot be FILETABLE and cannot contain FILESTREAM data type
• INSERT, UPDATE, and MERGE statements cannot reference and modify period columns; the start column is always set to system time, the end column to max date value
• INSTEAD OF triggers are not allowed
• TRUNCATE TABLE is not supported

The list of limitations for a history table is significantly longer and brings many additional restrictions. The following applies to the history table of a system-versioned temporal table:

• Cannot have constraints defined (primary or foreign keys, check, table, or column constraints). Only default column constraints are allowed.
• You cannot modify data in the history table.
• You can neither ALTER nor DROP a history table.
• It must have the same schema as the current table (column names, data types, ordinal position.
• Cannot be defined as the current table.
• Cannot be FILETABLE and cannot contain FILESTREAM data type.
• No triggers are allowed (neither INSTEAD OF nor AFTER).
• Change Data Capture and Change Data Tracking are not supported.

You can read more about considerations and limitations when working with temporal tables at https://msdn.microsoft.com/en-us/library/mt604468.aspx.

The list might look long and discouraging, but all these limitations are there to protect data consistency and accuracy in history tables. However, although you cannot change logical attributes, you can still perform actions related to the physical implementations of the history table: you can switch between rowstore and columnstore table storage, you can choose columns for clustered indexes, and you can create additional non-clustered indexes.