PostgreSQL, nebo MySQL: jeden benchmark vítěze databáze neurčí

Pro nový projekt volte mezi PostgreSQL a MySQL podle práce, kterou bude databáze skutečně vykonávat. PostgreSQL stojí za bližší zkoušku při častých agregacích a dotazech do JSON; MySQL s InnoDB může být vhodnou volbou pro přímočaré transakční operace, zvlášť pokud ho tým dobře provozuje. Samotné pořadí v cizím benchmarku rozhodnutí neuzavře.

Podstatný je poměr krátkých čtení, zápisů a náročnějších přehledů i požadované chování souběžných transakcí. Výsledek mění schéma, indexy, dostupná paměť a počet současných spojení. Srovnání má proto zahrnout vlastní dotazy a také provozní požadavky, například replikaci a obnovu po výpadku.

Co skutečně říká benchmark

V testu StaticBlock s PostgreSQL 16.1 a MySQL 8.3.0 zvládl MySQL 87 234 vložení za sekundu proti 81 523 u PostgreSQL, zatímco uvedené agregační spojení tabulek dokončil PostgreSQL za 3,42 sekundy proti 5,87 sekundy u MySQL. Jde o výsledky konkrétních úloh na konkrétních konfiguracích: rychlejší vkládání samo o sobě neříká, jak rychle poběží report nad objednávkami.

V testovaných konfiguracích se lišilo nastavení databázové paměti a každá strana používala jiný connection pooler. Naměřený čas tak patří celé sestavě, nejen databázovému jádru. Při rozhodování je navíc rozdíl mezi reportem spouštěným mimo špičku a reportem, který soutěží o prostředky s transakcemi zákazníků. Propustnost v jedné úloze nevystihne čekání pomalejších požadavků při jejich souběhu.

Dotazy, JSON a indexy

Rozdíl mezi jednoduchým čtením podle primárního klíče a agregací nad historií objednávek je pro výběr důležitější než obecné označení aplikace za „čtecí“. U analytických dotazů rozhodují spojované tabulky, filtry, seskupení a množství zpracovaných řádků. Pokud jsou takové přehledy součástí běžné odezvy produktu, musí mít v testu odpovídající váhu; vzácný report mimo špičku může mít pro volbu menší význam.

Pro časté hledání uvnitř dokumentů nabízí PostgreSQL typ jsonb. Jeho dokumentace indexování jsonb popisuje indexy GIN pro hledání klíčů a dvojic klíč–hodnota i rozdíly mezi obecnějším indexem a užším indexem pro konkrétní výraz. Samotná přítomnost JSON ve schématu tedy nerozhoduje: záleží na podobě podmínek v dotazech a na tom, zda pro ně vhodný index existuje. Při srovnání započtěte také prostor indexů a práci navíc při zápisech.

Izolace transakcí mění podmínky měření

PostgreSQL používá víceverzové řízení souběhu: běžné čtení neblokuje zápis a zápis neblokuje čtení; dokumentace popisuje zachování této vlastnosti i při úrovni Serializable Snapshot Isolation. To však neodstraňuje potřebu řešit konfliktní transakce v aplikaci. Na jejich chování mají vliv konkrétní příkazy, délka transakcí a případné zamykací čtení.

Také InnoDB používá při konzistentním čtení snímek dat. Podle dokumentace izolace InnoDB je výchozí úrovní REPEATABLE READ a dostupné jsou všechny čtyři standardní úrovně; u zamykacího čtení může rozsah zámků záviset na indexu a podmínce dotazu. Porovnání ponechané na výchozím nastavení by proto současně porovnávalo databáze i odlišná pravidla viditelnosti dat.

Nejprve určete požadovaný obchodní výsledek souběžných operací. U rezervace poslední dostupné položky například nestačí sledovat počet dokončených transakcí: důležité je, zda nevznikne dvojí rezervace, jak dlouho operace čeká a co aplikace udělá po konfliktu. Pro oba kandidáty nastavte úroveň izolace odpovídající požadavku a rozdíly v jejím chování ověřte samostatným souběžným scénářem.

Replikace a zkušenost týmu

Požadavek na čtení z repliky nebo předávání změn dalšímu systému přidává k výkonu primární databáze další otázky. PostgreSQL nabízí logickou replikaci, při níž odběratel přebírá publikovaná data a jejich následné změny. Pro konkrétní projekt je podstatné, která data se mají přenášet, jak čerstvá musí být na odběrateli a jak bude aplikace fungovat během výpadku či návratu repliky.

Do nákladů volby patří také schopnost týmu databázi spravovat. Znalost pomalých dotazů, zálohování, obnovy a řešení potíží s replikou má při incidentu přímý dopad na provoz. Přechod na méně známý systém může vyžadovat čas na osvojení nástrojů; setrvání u známého systému zase nemusí být výhodné, pokud jeho provozní postupy nevyhovují klíčovým dotazům aplikace.

Krátký rozhodovací strom

• Převažují krátké transakce nad dobře indexovanými tabulkami a tým zná MySQL? Začněte měřením MySQL s InnoDB. PostgreSQL ponechte v testu, pokud očekáváte složitější dotazy nebo se výsledky krátkých operací ukážou jako těsné.
• Patří agregace, spojování velkých tabulek nebo filtrování uvnitř JSON k běžné funkci produktu? Začněte měřením PostgreSQL. Současně sledujte, jak potřebné indexy ovlivní zápisy a velikost databáze.
• Závisí správnost na souběžných změnách stejných dat? Určete nejdříve pravidla izolace a opakování neúspěšné transakce. Teprve poté má smysl porovnávat výkon operací, které dávají správný výsledek.
• Budou zásadní repliky a rychlá obnova? Přidejte do srovnání zpoždění přenosu změn a provozní postup při poruše. Rychlost dotazu na primárním uzlu pak představuje jen část rozhodnutí.

Vlastní A/B benchmark nad schématem projektu

1. Připravte stejné logické schéma a srovnatelný objem i rozložení dat. Sada dotazů má odpovídat zamýšlenému provozu: zahrňte čtení jednotlivých záznamů, vkládání, aktualizace a podle potřeby také agregace či dotazy do JSON. Zachovejte očekávaný poměr operací a velikost vracených výsledků.
2. Pro každou databázi navrhněte indexy vhodné pro její způsob vykonávání dotazů a ověřte plány důležitých operací. Cílem není stejný počet indexů, ale stejná funkce aplikace a správný výsledek. Zaznamenejte jejich prostorové nároky i dopad na rychlost zápisů.
3. Stanovte společný rozpočet výpočetního výkonu, paměti, úložiště a sítě. Do spotřeby zahrňte celý testovaný provoz včetně pooleru; sjednoťte počet klientů, kapacitu poolingu a pravidla potvrzování zápisů. Izolaci nastavte podle požadovaného chování aplikace a zaznamenejte rozdíly, které se mezi systémy nepodaří vyjádřit totožně.
4. Po zahřátí opakujte scénáře při běžné i špičkové souběžnosti. Vedle propustnosti měřte typickou odezvu, pomalejší požadavky, čekání na zámky, neúspěšné transakce a spotřebu prostředků. Mají-li reporty v provozu běžet současně se zápisy, spusťte je společně i v testu.
5. Výsledky vztáhněte k požadavkům produktu na odezvu, správnost a dostupnost. Pokud se pořadí změní po úpravě indexu nebo poolingu, zaznamenejte obě konfigurace a jejich provozní cenu. Pro volbu má největší váhu opakovaně lepší výsledek u operací, které budou pro aplikaci skutečně rozhodující.

Přečtěte si také:

• Lokální LLM, nebo cloud: levnější volbu mění vytížení
• Ko-fi, nebo Buy Me a Coffee: pětiprocentní poplatek mění vítěze
• Claude Code, nebo Codex: benchmark nezná váš repozitář