För det första använder Solr inte B-träd. Ett Lucene-index (det underliggande biblioteket som används av Solr) består av ett skrivskyddat segment
. För varje segment upprätthåller Lucene en termordbok, som består av listan med termer som förekommer i segmentet, lexikografiskt sorterade. Att slå upp en term i denna termordbok görs med en binär sökning, så kostnaden för en engångsuppslagning är O(log(t)) där t är antalet termer. Tvärtom, att använda indexet för en standard RDBMS kostar O(log(d)) där d är antalet dokument. När många dokument delar samma värde för något fält kan detta vara en stor vinst.
Dessutom lade Lucene committer Uwe Schindler till stöd för mycket presterande numeriska intervallfrågor några år sedan. För varje värde av en numeriskt fält , Lucene lagrar flera värden med olika precision. Detta gör att Lucene kan köra intervallfrågor mycket effektivt. Eftersom ditt användningsfall verkar utnyttja numeriska intervallfrågor mycket, kan detta förklara varför Solr är så mycket snabbare. (För mer information, läs javadocs som är mycket intressanta och ger länkar till relevanta forskningsartiklar.)
Men Solr kan bara göra detta eftersom det inte har alla begränsningar som en RDBMS har. Till exempel är Solr väldigt dåliga på att uppdatera ett enda dokument åt gången (det föredrar batchuppdateringar).