> Well, you can’t do that with an equals filter. But how often do you use non-equals filters like > or < on the primary key? You can; he's wrong. He missed the

> Well, you can’t do that with an equals filter. But how often do you use non-equals filters like > or < on the primary key? You can; he's wrong. He missed the vastly more common scenario: your primary key is a composite key and you're filtering on a prefix of that composite key. We do that all the time. No < or > required; you get a range of keys with an equijoin. It's additionally common for the first key in the composite key to be some kind of timestamp or monotonically increasing value, so new writes always go together at the end of the table. This sort of key is absolutely begging to be used with a clustered primary key index. We have a table with 100+ billion rows that uses this pattern. It uses partition switching to append new data. At this size it is absolutely imperative to reduce the number of indexes to keep insert performance high, and we are always querying multiple consecutive rows based on a prefix equijoin. I'd be a fool to follow the author's advice here. I suspect the author and I live in very different worlds, and he doesn't know my world exists.