Jak porównujemy backend: powtarzalna metodologia

Convex, wydawca konkurencyjnego, responsywnego backendu, publicznie zdystansował się od tego, co jego zespół techniczny nazywa „wojną na wykresy słupkowe” pomiędzy dostawcami baz danych. Jego formuła jest prosta: „To teatr skalowania, a nie skalowanie” – teatr skalowania, a nie prawdziwe skalowanie (stack.convex.dev/on-competitive-benchmarks, Blog techniczny Stack, dostęp 23 sierpnia 2026).

Jego główny argument: benchmark, który porównuje dwa systemy z różnymi gwarancjami spójności, topologii lub modelu cenowego, często nie testuje tego samego, nawet jeśli tak twierdzi – „benchmark nie testuje w rzeczywistości tego samego”. Ten odruch ma swoją nazwę w branży: benchmarking, publikujący dane liczbowe wybrane ze względu na efekt marketingowy, a nie rygor metodologiczny.

Naszą odpowiedzią nie jest odmowa dokonania pomiaru — odmowa opublikowania danych liczbowych w nieskończoność byłaby równie nieuczciwa, jak opublikowanie danych bezpodstawnych. Chodzi o to, aby najpierw udokumentować, w jaki sposób byśmy mierzyli, za pomocą jakich narzędzi i w jakich warunkach, zanim będziemy twierdzić, że cokolwiek zmierzyliśmy. To także odróżnia przydatne porównanie (takie jak nasze porównanie Aurabase vs Appwrite, które dokumentuje sprawdzalne różnice w architekturze) od porównania wydajności bez wspólnego protokołu.

Jest to szczególnie ważne w przypadku kierownika technicznego lub dyrektora technologicznego, który musi bronić wyboru zaplecza w komisji technicznej: liczba, której nie można powiązać z metodą, nie przetrwa pierwszego, nieco natarczywego pytania. Udokumentowany protokół broni się sam — możesz pokazać skrypt, przetestowaną wersję i, jeśli zajdzie taka potrzeba, ponownie przeprowadzić test w obecności innej osoby.

Systematycznie pojawiają się dwie pułapki: porównywanie różnych topologii bez zgłaszania tego i mierzenie opóźnień w sposób, który dokładnie ukrywa pauzy, które są dla użytkownika najważniejsze.

W pierwszym punkcie PlanetScale wyraźnie dokumentuje swoje sprzętowe ograniczenie parzystości: każde porównywane środowisko musi działać na zasobach obliczeniowych (vCPU, RAM) równych lub większych niż instancja referencyjna, w tym samym regionie chmury (planetscale.com/benchmarks, metodologia „Telescope”, dostęp 23 sierpnia 2026 r.). Bez tej dyscypliny luka w opóźnieniu może po prostu odzwierciedlać większą maszynę, a nie szybszą architekturę.

Ta sama zasada dotyczy stanu pamięci podręcznej i topologii sieci. Instancja, która właśnie została uruchomiona (zimna pamięć podręczna Postgres, pusta pula połączeń, plan zapytań jeszcze nie buforowany) odpowiada strukturalnie wolniej niż instancja działająca przez godzinę przy stabilnym obciążeniu. Zapytanie z tego samego regionu co baza danych odpowiada strukturalnie szybciej niż zapytanie między regionami. Dwa testy porównawcze, które nie określają żadnego z nich, po prostu nie są porównywalne, nawet jeśli wyświetlają identyczne jednostki.

W drugim punkcie pułapka nazywa się skoordynowanym pominięciem. HdrHistogram, projekt referencyjny dotyczący pomiaru opóźnień stworzony przez Gila Tene, wyjaśnia to w ten sposób: kiedy generator obciążenia czeka na odpowiedź na żądanie przed wysłaniem kolejnego (zamknięta pętla), pauza usługi automatycznie zmniejsza liczbę żądań wysłanych podczas pauzy — a tym samym liczbę zarejestrowanych pomiarów o dużym opóźnieniu (github.com/HdrHistogram/HdrHistogram, dostęp w sierpniu 23.2026). W projekcie przedstawiono konkretny i wymierny przykład: w hipotetycznym systemie, który próbkuje opóźnienie co 10 ms przez 200 sekund, pojedyncza przerwa trwająca 100 sekund w środku testu wystarczy, aby bez korekty uzyskać histogram, na którym około 99,99% odpowiedzi wydaje się mieścić w czasie krótszym niż 1 ms – mimo że w tej pojedynczej pauzie upłynęła połowa czasu rzeczywistego.

Średnie opóźnienie może wydawać się doskonałe, gdy jedno na dwadzieścia żądań trwa pięć razy dłużej. To właśnie ujawniają percentyle i to, co strukturalnie ukrywa średnia.

Mechanicznie nie ma nic tajemniczego w percentylu: posortuj wszystkie zmierzone opóźnienia w porządku rosnącym, a następnie weź wartość z odpowiedniej pozycji. Spośród 1000 posortowanych zapytań p50 to 500. wartość, p95 to 950., p99 to 990. Pojedyncze wyjątkowo powolne żądanie spośród 1000 wystarczy, aby p99 zaczął działać - właśnie jego wrażliwość na rzadkie przypadki czyni go użytecznym, gdy to samo izolowane żądanie nie ma prawie żadnego wpływu na średnią.

Znak ostrzegawczy: raport tekstowy, który pgbench — oficjalne narzędzie do testowania PostgreSQL — wyświetla domyślnie, podaje średnią i odchylenie standardowe , a nie percentyle (postgresql.org/docs/current/pgbench.html, dostęp 23 sierpnia 2026 r.). Oficjalna dokumentacja ostrzega również: „Nigdy nie wierz żadnemu testowi, który trwa tylko kilka sekund” – nigdy nie wierz testowi, który trwa tylko kilka sekund, co dotyczy zarówno czasu trwania, jak i wybranej metryki.

k6, narzędzie do ładowania, którego używamy na poziomie 2 naszego pakietu, rozwiązuje ten problem za pomocą progów wyrażonych w percentylach: składnia p(95)<500 definiuje kryterium pozytywnego/niepomyślnego — 95% żądań musi odpowiedzieć w ciągu 500 ms — bezpośrednio w konfiguracji testowej (grafana.com/docs/k6, konsultowano 23 sierpnia 2026 r.).

Publikowanie metodologii bez prawdziwych narzędzi byłoby po prostu kolejną formą teatru. Folder benchmarks/ w repozytorium Aurabase zawiera już 3-poziomowy pakiet, inspirowany swoją strukturą publiczną metodologią Supabase - narzędzia istnieją, zmierzonych i datowanych wyników jeszcze nie ma.

Poziom 1 – Mikrotesty porównawcze Criterion.rs

Trzy skrzynki obszaru roboczego Cargo mają dedykowane testy porównawcze związane z procesorem: aura-crypto (hasz Argon2, JWT HS256 — generowanie, sprawdzanie poprawności i podpis dla PostgREST, szyfrowanie AES-GCM), aura-db-adapters (filtry parsujące i select w formacie PostgREST — eq., gte., in.(), osadzanie relacji) i aura-core (serializacja JSON, rozdzielczość schema_name, sprawdzanie poprawności UUID).

// Rzeczywisty ekstrakt z repozytorium
let mut group = c.benchmark_group("jwt/hs256");

group.bench_function("generate", |b| {
    b.iter(|| jwt::generate_access_token(
        black_box(user_id), black_box(project_id),
        black_box("authenticated"), black_box(SECRET),
    ))
});

group.bench_function("validate", |b| {
    b.iter(|| jwt::validate_token(black_box(&token), black_box(SECRET)))
});

aura-db-adapters specjalnie mierzy koszt analizowania zapytań w formacie PostgREST — cztery przypadki dla filtrów (simple_4, complex_10, or_group, in_large_50 z 50 wartościami) i cztery dla select (pojedyncze kolumny, *, jedno osadzenie relacji, pięć osad). Jest to rodzaj kosztu niewidocznego w globalnym teście obciążenia: regresja na podstawie analizy złożonego filtru or.(...) nie zmieniłaby prawie nic w p95 mało używanego punktu końcowego, ale stałaby się mierzalna na punkcie końcowym o dużym ruchu - stąd zainteresowanie wyizolowaniem go w mikrotestie porównawczym, zamiast polegania wyłącznie na poziomie 2.

aura-core przyjmuje inne podejście: zamiast mierzyć surowy czas, mierzy przepustowość (Throughput::Bytes) serializacji i deserializacji JSON wewnętrznych komunikatów NatsRequest/NatsResponse wymienianych między bramą a usługami — z trzema realistycznymi rozmiarami ładunku (żądanie minimalne, żądanie z zagnieżdżoną treścią JSON, odpowiedź na liście 50-liniowej).

group.throughput(Throughput::Bytes(
    serde_json::to_vec(&small).unwrap().len() as u64
));
group.bench_function("NatsRequest/small", |b| {
    b.iter(|| serde_json::to_vec(black_box(&small)).unwrap())
});

Criterion.rs nie tylko mierzy czas pętli. Najpierw przeprowadza fazę rozgrzewania w celu wypełnienia pamięci podręcznej procesora/systemu operacyjnego, wykrywa wartości odstające za pomocą zmodyfikowanej wersji metody Tukeya (bez wykluczania ich ze zbioru danych), oblicza przedziały ufności poprzez ładowanie początkowe na dużej liczbie ponownie próbkowanych próbek i wykrywa regresje wydajności między dwoma przebiegami za pomocą testu statystycznego Studenta z konfigurowalnym progiem szumu — zwykle ± 1% — w celu zignorowania odchyleń, które nie są statystycznie istotne (bheisler.github.io/criterion.rs/book/analytic.html, dostęp: 23 sierpnia 2026 r.).

Poziom 2 — testowanie obciążenia k6

Osiem skryptów k6 obejmuje bramę po stronie płaszczyzny danych: health (linia bazowa opóźnienia), auth-flow (rejestracja → logowanie → odświeżenie → wylogowanie), crud-read i crud-write, storage (przesyłanie/pobieranie), realtime-ws, breakpoint (wzrost obciążenia aż do awarii) i supabase-compare. Siedem z nich jest podłączonych do dedykowanego celu Makefile — supabase-compare.js istnieje w repozytorium, ale nie ma jeszcze celu. Stan rzeczy ten artykuł dokumentuje jako taki, a nie go ukrywa.

export const options = {
  scenarios: {
    crud_read: {
      executor: 'ramping-vus',
      startVUs: 10,
      stages: [
        { duration: '30s', target: 50 },
        { duration: '1m', target: 200 },
        { duration: '30s', target: 0 },
      ],
    },
  },
  thresholds: THRESHOLDS_READ,
}

Konfiguracja udostępniona definiuje progi według typu operacji. Są to kryteria pozytywne/negatywne, które test sprawdza przy każdym uruchomieniu — a nie wyniki, które zostały już zmierzone:

Poziom 3 — Bezpośrednie porównanie PostgreSQL z API

Skrypt Pythona (direct_vs_api.py) mierzy rzeczywisty narzut bramy + warstwy usług, porównując bezpośrednie żądania psycopg2 z wywołaniami HTTP w ramach tej samej operacji — lista, jednorazowy odczyt według identyfikatora, filtrowany i sortowany odczyt. Każdy pomiar następuje po 10 iteracjach rozgrzewania przed pętlą czasową, następnie oblicza średnią, p50, p95, p99 i przepustowość operacji na sekundę.

def percentile(data, p):
    k = (len(data) - 1) * (p / 100)
    f = int(k)
    c = f + 1
    if c >= len(data):
        return data[f]
    return data[f] + (k - f) * (data[c] - data[f])

Drugi skrypt (aurabase_vs_supabase.py) stosuje tę samą logikę rozgrzewania i obliczania percentyli do bezpośredniego porównania z lokalną instancją Supabase (Supabase CLI, domyślnie localhost:54321) — ta sama maszyna, ta sama sieć lokalna dla obu, dokładnie taka sama dyscyplina parzystości środowiska, którą PlanetScale dokumentuje dla własnych porównań.

Skrypt orkiestracji (collect_baseline.sh, cel bench-baseline z Makefile) łączy trzy poziomy — kryterium na 3 skrzyniach, podzbiór scenariuszy k6 (health i crud-read dzisiaj, jeszcze nie wszystkie 8), następnie porównanie Pythona — i zapisuje dzienniki, raporty JSON i kryteria HTML w folderze z unikalnym znacznikiem czasu: benchmarks/results/AAAAMMJJ_HHMMSS/. Jest to dokładnie odruch datowanego ujawnienia w pojedynczej powtarzalnej serii, który poniższa sekcja formalizuje w pełnym protokole.

Osiem zobowiązań, każde zakotwiczone w praktyce udokumentowanej już przez uznane narzędzie lub projekt strony trzeciej – nie wymyślone na tę okazję.

1. Podgrzewanie wstępne niezależnie od pomiaru. Criterion.rs wypełnia pamięć podręczną procesora/systemu operacyjnego przed synchronizacją; pgbench wyraźnie zaleca, aby nigdy nie wierzyć biegowi trwającemu zaledwie kilka sekund.
2. Stały czas trwania, a nie stała liczba iteracji. Obciążenie potrzebuje czasu na osiągnięcie zbieżności — taka jest rola stages k6 i flagi -T pgbench.
3. Percentyle, nigdy tylko średnia — i aktywna czujność w przypadku skoordynowanych pominięć, jeśli generator obciążenia działa w pętli zamkniętej.
4. Środowisko szczegółowo udokumentowane: zatwierdzenie git testowanej usługi, wersja PostgreSQL, specyfikacja sprzętu, wersja narzędzia ładującego. PlanetScale dokumentuje dokładne parametry TPCC (TABLES=20, SCALE=250, ~500 GB) właśnie z tego powodu — bez tych szczegółów nikt nie będzie w stanie odtworzyć przebiegu.
5. Wyniki ze znacznikiem czasu i wersją, na stronie marketingowej nigdy nie jest wygrawerowana żadna liczba bez daty. Obecne oprzyrządowanie jest już zapisane w przestarzałym pliku; konieczne będzie rozszerzenie tego odruchu na wszelkie publicznie publikowane pomiary, z regionem przyjmującym udokumentowanym jak każdą inną zmienną środowiskową (zobacz nasz przewodnik na temat suwerenności UE przyjmującej, istotne, gdy liczba zależy od danego regionu).
6. Skrypty i surowe dane publikowane są wraz z wynikami zbiorczymi, a nie tylko końcową średnią. PlanetScale zaprasza nawet czytelników do zgłaszania błędu metodologicznego pod dedykowanym adresem – postawy, którą uważamy za zdrową i którą chcemy wznowić.
7. Reklamowana przepustowość wraz z opóźnieniami, a nie tylko jedno lub drugie. System może charakteryzować się doskonałymi opóźnieniami przy niskim obciążeniu i spadkiem przepustowości wraz ze wzrostem współbieżności — właśnie to ma ujawnić scenariusz breakpoint (skalowalność do awarii) naszego pakietu k6 i co wychwytuje pomiar mikrobenchmarku Throughput::Bytes firmy Criterion na poziomie funkcji.
8. Znacząca luka przed ogłoszeniem poprawy. Kilkuprocentowa różnica między dwoma seriami może oznaczać szum pomiarowy, a nie rzeczywisty zysk — Criterion.rs oblicza prawdopodobieństwo, że zaobserwowana różnica jest wynikiem przypadku, zanim zakwalifikuje ją jako regresję lub poprawę. Wyodrębniona liczba, bez tej weryfikacji, jest jedynie statystyczną anegdotą.

Ta lista liczy się tak samo, jak powyższy protokół pozytywny.

• Porównywanie różnych topologii (instancja hostowana samodzielnie i zarządzana, instancja zimna i wstępnie podgrzewana) bez jawnego zgłaszania tego.
• Zachowaj najlepszy wynik z dziesięciu, nie wspominając o pozostałych dziewięciu.
• Publikuj rycinę bez daty, bez wersji serwisowej, bez skryptu reprodukcji.
• Opublikuj ponownie istniejące dane marketingowe, o ile nie są powiązane z niniejszym protokołem.
• Porównywanie się z konkurentem na podstawie surowych wyników, jeśli ten konkurent nie publikuje własnej metodologii w równoważny sposób — liczba kontra cisza nie jest porównaniem, to slogan.

Protokół ten nie jest zależny od żadnego konkretnego narzędzia Aurabase — możesz go już dziś zastosować do własnego API.

1. Ustaw obciążenie przed narzędziem: tylko do odczytu, do zapisu, realistyczny miks dla Twojej aplikacji — a nie ogólny współczynnik skopiowany z innego projektu.
2. Należy wyraźnie oddzielić fazę podgrzewania od fazy pomiaru.
3. Uruchom test wystarczająco długo — minuty, a nie sekundy.
4. Mierz w percentylach (p50/p95/p99), nigdy samodzielnie.
5. Sprawdź, czy generator obciążenia nie znajduje się w pętli zamkniętej, lub popraw pominięcie koordynacji w analizie.
6. Izoluj testowane środowisko — bez hałaśliwych sąsiadów i bez konkurencyjnych zadań w tle.
7. Opublikuj testowaną wersję, datę, specyfikację sprzętu i skrypt — a nie tylko wynik końcowy.

Na czystej bazie Postgres protokół ten wymaga jednego polecenia pgbench — 20 równoczesnych klientów rozproszonych w 4 wątkach przez 5 minut, z raportem postępu co 10 sekund:

# Zainicjuj testowy zbiór danych (współczynnik skali >= liczba klientów)
pgbench -i -s 50 ma_base

# -c współbieżni klienci, -j wątki, -T czas trwania w sekundach, -P interwał raportowania
pgbench -c 20 -j 4 -T 300 -P 10 ma_base

Pięć narzędzi, każde dostosowane do innego poziomu stosu — żadne nie zastępuje pozostałych.