I&#x27;ve come to believe that designing systems like SQL to have queries that work transparently whether or not an index exists is wrong. There may be people that don&#x27;t care how their query is actually executed, but I doubt it&#x27;s the common case.<p>So many times I&#x27;ve fought or watched other developers fight with getting a DBMS to use an index. Or been surprised to find out that production doesn&#x27;t have that index but staging does. Or found out that someone added a lower() to a query that made the index stop working. Or found out that index turns out to be more expensive than scanning the table directly in a circumstance that is different between instances of the same software.<p>Contrast that to an API like the Cassandra Thrift interface. You know if you&#x27;re doing something expensive because the API only exposes the cheap things. It doesn&#x27;t have an implicit sequential scan. You know you&#x27;re doing one because you had to type out `while(next=...)` right in your code.<p>Something as simple as<p><pre><code>    SELECT mycolumn FROM mytable WHERE INDEXED b=5
</code></pre>
vs<p><pre><code>    SELECT mycolumn FROM mytable WHERE SCAN b=5
</code></pre>
and refusing to run if the assertion isn&#x27;t met would go a long way to making the API predictable