Why CHANGETABLE is Slower Than Indexed rowversion in SQL Server

When implementing incremental data synchronization in SQL Server, developers often choose between SQL Server Change Tracking (CT) and a custom implementation using a rowversion (timestamp) column with a non-clustered index. While official documentation highlights Change Tracking as a purpose-built, lightweight mechanism, practical benchmarks frequently reveal that CHANGETABLE(CHANGES ...) generates a significantly heavier execution plan and higher read latency than an indexed rowversion query—even when returning a single changed row.

The Core Reason: Internal Table Indexing

To understand why CHANGETABLE is slower for range queries, you have to look at how SQL Server indexes internal Change Tracking data versus how your custom rowversion index works.

1. The rowversion Approach: Direct B-Tree Seek

When you create a non-clustered index on a rowversion column: