For det første bruger Solr ikke B-træer. Et Lucene (det underliggende bibliotek brugt af Solr) indeks er lavet af et skrivebeskyttet segmenter
. For hvert segment vedligeholder Lucene en termordbog, som består af listen over termer, der optræder i segmentet, leksikografisk sorteret. At slå et udtryk op i denne termordbog er lavet ved hjælp af en binær søgning, så prisen for et enkelt-term opslag er O(log(t)) hvor t er antallet af led. Tværtimod koster brug af indekset for en standard RDBMS O(log(d)) hvor d er antallet af dokumenter. Når mange dokumenter deler den samme værdi for nogle felter, kan dette være en stor gevinst.
Desuden tilføjede Lucene committer Uwe Schindler støtte til meget effektive numeriske forespørgsler et par år siden. For hver værdi af en numerisk felt , gemmer Lucene flere værdier med forskellig præcision. Dette gør det muligt for Lucene at køre rækkeforespørgsler meget effektivt. Da din use-case ser ud til at udnytte numeriske forespørgsler meget, kan dette forklare, hvorfor Solr er så meget hurtigere. (For mere information, læs javadocs, som er meget interessante og giver links til relevante forskningsartikler.)
Men Solr kan kun gøre dette, fordi det ikke har alle de begrænsninger, som et RDBMS har. For eksempel er Solr meget dårlig til at opdatere et enkelt dokument ad gangen (det foretrækker batchopdateringer).