Generelt, hvis du ikke bruger RAC, ville der ikke være nogen grund til at bruge et omvendt nøgleindeks.
Fra et præstationssynspunkt er du meget bedre stillet at have en eller to hot-blokke på et givet tidspunkt, der er underlagt indsættelser, fordi det i det væsentlige garanterer, at de varme blokke vil være i buffercachen og INSERT behøver ikke at pådrage sig omkostningerne ved at læse blokken fra disken. Hvis du har indsættelser, der går ind i tilfældige blokke i et indeks, er der en meget større sandsynlighed for, at den ønskede blok ville være ældet ud af cachen og ville pådrage sig omkostningerne ved en fysisk I/O.
Omkostningerne ved at holde et indeks afbalanceret er ret minimale, men selv det favoriserer et standardindeks. Hvis du har en sekvensgenereret primærnøgle med et normalt indeks, vil Oracle lave en 90/10 blokopdeling på blok længst til højre, når denne blok fyldes op. I modsætning hertil, hvis du har et omvendt nøgleindeks, skal Oracle gøre 50/50 blokopdelinger hver gang en given blok fyldes op. En 50/50 blokopdeling kopierer halvdelen af dataene fra den gamle blok til den nye blok, en 90/10 blokopdeling kopierer kun dataværdien længst til højre til den nye blok. 90/10 blokopdelingen er derfor meget billigere end en 50/50 blokopdeling, og du skal lave nogenlunde det samme antal blokopdelinger, uanset hvilken type indeks du vælger. Så omkostningerne ved at vedligeholde et almindeligt indeks er mindre end omkostningerne ved at vedligeholde et omvendt nøgleindeks, selv når man ignorerer effekten af cache.
Grunden til at du ville overveje at bruge et omvendt nøgleindeks ville være, at du bruger RAC, og du vil undgå omkostningerne ved at have mange RAC-noder, der alle kæmper om den samme hot-blok. Hvis du hele tiden skal sende den varme blok fra en node til en anden for at lave den næste indsættelse, kan det være umagen værd at bruge et omvendt nøgleindeks i stedet for at reducere denne påstand. Hvis du har licenseret partitioneringsindstillingen, ville det være bedre at bruge et hash-partitioneret indeks i stedet for (dette kan gøres uanset om tabellerne er partitioneret eller ej). Hvis du ikke har licenseret partitioneringsmuligheden, kan et omvendt nøgleindeks være godt nok til at løse konflikter på hot block til ikke at kræve, at du licenserer partitionering.