Podczas przygotowań do aktualizacji Sei Giga, Sei Labs przeprowadziło testy wydajności węzłów, używając różnych backendów do przechowywania stanu. Porównując RocksDB i PebbleDB z MVCC dla zapytań historycznych z dużym obciążeniem indeksowania, RocksDB był w stanie zredukować opóźnienie operatora węzła o 10–40×.

Zmierzono opóźnienie traceBlock w kilku milionach bloków — zapytanie RPC, które wykonuje rozbudowaną iterację po parach klucz/wartość w magazynie stanu. W miarę wzrostu historii węzła czas iteracji PebbleDB rośnie dramatycznie, podczas gdy RocksDB utrzymuje znacznie bardziej płaską krzywą opóźnienia.

Głównym powodem tej różnicy jest projekt backendu. RocksDB obsługuje natywne znaczniki czasu zdefiniowane przez użytkownika dla MVCC oraz efektywne rodziny kolumn. PebbleDB, w przeciwieństwie do tego, nie ma natywnego wersjonowania, co wymaga dodawania sufiksów do kluczy i ręcznej iteracji po wielu wersjach.

To prowadzi do znacznie lepszej efektywności iteracji w RocksDB — szczególnie dla węzłów z dużym stanem historycznym. W miarę wzrostu przechowywanej historii, różnica w wydajności między PebbleDB a RocksDB staje się bardziej wyraźna.

Chociaż RocksDB wprowadza niewielki kompromis w budowie, poprawa wydajności czyni go silną opcją dla węzłów archiwalnych i RPC obsługujących dużą ilość stanu lub długą historię. Obserwowaliśmy stałe poprawy w opóźnieniu śledzenia i prędkości iteracji w różnych konfiguracjach.