Also the desire to have more than "The Ozar 5" indexes on a table probably indicates that you have lots of different kinds of read-heavy queries on the table.

Which probably indicates that you could benefit from a clustered or non-clustered columnstore index on the table.

Instead of having the optimtimal index for each of N different access paths, a columnstore gives you super-fast scanning and the ability to skip unneeded columns, and row segments. So you can have a small number of BTree indexes for super-critical transactions, and fall back to the columnstore for everything else.

Columnstore indexes are designed to work in OLTP-heavy workloads with SQL Server 2016+. See the documentation for Real-time operational analytics.

Also the desire to have more than "The Ozar 5" indexes on a table probably indicates that you have lots of different kinds of read-heavy queries on the table.

Which probably indicates that you could benefit from a clustered or non-clustered columnstore index on the table.

Instead of having the optimal index for each of N different access paths, a columnstore gives you super-fast scanning and the ability to skip unneeded columns, and row segments. So you can have a small number of B-Tree indexes for super-critical transactions, and fall back to the columnstore for everything else.

Columnstore indexes are designed to work in OLTP-heavy workloads with SQL Server 2016+. See the documentation for Real-time operational analytics.

Also the desire to have more than "The Ozar 5" indexes on a table probably indicates that you have lots of different kinds of read-heavy queries on the table.

Which probably indicates that you could benefit from a clustered or non-clustered columnstore index on the table.

Instead of having the optimtimal index for each of N different access paths, a columnstore gives you super-fast scanning and the ability to skip unneeded columns, and row segments. So you can have a small number of BTree indexes for super-critical transactions, and fall back to the columnstore for everything else.

Also the desire to have more than "The Ozar 5" indexes on a table probably indicates that you have lots of different kinds of read-heavy queries on the table.

Which probably indicates that you could benefit from a clustered or non-clustered columnstore index on the table.

Instead of having the optimtimal index for each of N different access paths, a columnstore gives you super-fast scanning and the ability to skip unneeded columns, and row segments. So you can have a small number of BTree indexes for super-critical transactions, and fall back to the columnstore for everything else.

Columnstore indexes are designed to work in OLTP-heavy workloads with SQL Server 2016+. See the documentation for Real-time operational analytics.