Ten eerste gebruikt Solr geen B-trees. Een Lucene-index (de onderliggende bibliotheek die door Solr wordt gebruikt) is gemaakt van een alleen-lezen segmenten
. Voor elk segment houdt Lucene een termenwoordenboek bij, dat bestaat uit de lijst met termen die in het segment voorkomen, lexicografisch gesorteerd. Het opzoeken van een term in deze term woordenboek wordt gemaakt met behulp van een binaire zoekopdracht, dus de kosten van een enkele term opzoeken is O(log(t)) waarbij t het aantal termen is. Integendeel, het gebruik van de index van een standaard RDBMS kost O(log(d)) waarbij d het aantal documenten is. Als veel documenten dezelfde waarde hebben voor een bepaald veld, kan dit een grote overwinning zijn.
Bovendien heeft Lucene-committer Uwe Schindler ondersteuning toegevoegd voor zeer performante query's met numeriek bereik een paar jaar geleden. Voor elke waarde van een numeriek veld , Lucene slaat verschillende waarden op met verschillende precisies. Hierdoor kan Lucene bereikquery's zeer efficiënt uitvoeren. Aangezien uw use-case veel gebruik lijkt te maken van numerieke bereikquery's, kan dit verklaren waarom Solr zo veel sneller is. (Lees voor meer informatie de javadocs die erg interessant zijn en links geven naar relevante onderzoekspapers.)
Maar Solr kan dit alleen doen omdat het niet alle beperkingen heeft die een RDBMS heeft. Solr is bijvoorbeeld erg slecht in het bijwerken van een enkel document tegelijk (het geeft de voorkeur aan batchupdates).