PostgreSQL 19 je ve druhé betě, grafové dotazy zvládne nad běžnými tabulkami

Vývojářské sdružení PostgreSQL Global Development Group vydalo 16. července 2026 druhou betu databáze PostgreSQL 19. Beta není hotové vydání a projekt to říká rovnou: „některé podrobnosti vydání se během beta období mohou změnit“ (přeloženo z angličtiny). Ostrou verzi čeká na září nebo říjen 2026 a do té doby počítá s dalšími betami a s jednou či více kandidátskými verzemi.

Za pozornost stojí hlavně to, co se do devatenáctky dostalo už v první betě ze 4. června 2026. Jednou větou: relační databáze se naučila dotazovat grafy.

Graf bez grafové databáze

Grafem se v informatice myslí struktura z uzlů a spojnic mezi nimi – lidé a jejich známosti, zákazníci a jejich objednávky, letiště a linky. Data v tomhle tvaru se v běžném SQL dotazují mizerně: každý další krok po spojnici znamená další JOIN a dotaz rychle přeroste přes hlavu. Proto vznikly zvláštní grafové databáze a s nimi povinnost udržovat data na dvou místech.

PostgreSQL 19 zavádí podporu SQL/PGQ, tedy části normy SQL věnované dotazům nad grafy. Podle oznámení projektu umožňuje „provádět dotazy nad grafy vlastností pomocí syntaxe podle normy SQL“ (přeloženo). Grafem se přitom nestává nic nového – jen se nad existující tabulky položí popis, co je uzel a co spojnice:

CREATE PROPERTY GRAPH myshop
    VERTEX TABLES (
        products,
        customers,
        orders
    )
    EDGE TABLES (
        order_items SOURCE orders DESTINATION products,
        customer_orders SOURCE customers DESTINATION orders
    );

Dotaz se pak píše konstrukcí GRAPH_TABLE, ve které se cesta grafem kreslí šipkami:

SELECT customer_name FROM GRAPH_TABLE (myshop
    MATCH (c IS customers)-[IS customer_orders]->(o IS orders
        WHERE o.ordered_when = current_date)
    COLUMNS (c.name AS customer_name));

Výsledkem je obyčejná tabulka, se kterou se dá dál pracovat jako s čímkoli jiným. Server InfoQ shrnul význam té změny tak, že PostgreSQL 19 „umožňuje grafové dotazy nad existujícími relačními tabulkami, aniž by byla potřeba samostatná grafová databáze nebo přesun dat“ (přeloženo).

Přestavba tabulky skoro bez zámku

Druhou novinkou je příkaz REPACK. Ten přepíše celý obsah tabulky do nového souboru na disku bez volného místa navíc, takže se místo po smazaných řádcích vrátí operačnímu systému. Dosud se totéž dělalo příkazem VACUUM FULL, o kterém dokumentace píše, že „vyžaduje zámek ACCESS EXCLUSIVE na každou zpracovávanou tabulku“ (přeloženo) – tedy nejpřísnější druh zámku, po jehož dobu se s tabulkou nedá dělat vůbec nic.

Podstatná je u REPACKu volba CONCURRENTLY. S ní se podle dokumentace tvrdý zámek bere „jen na výměnu souborů tabulky a indexu“; změny, které mezitím do tabulky přišly, se zachytí logickým dekódováním a dohrají předtím, než si příkaz o zámek řekne. Zámek se tak drží jen krátce, ne po celou dobu přestavby.

Vstupy a výstupy, které se ladí samy

Asynchronní vstupně-výstupní podsystém přišel do PostgreSQL už v osmnáctce. Zjednodušeně: databáze nečeká na každé čtení z disku, ale zadá jich víc naráz a zpracovává je, jak se vracejí. Nevýhodou bylo, že počet pracovních procesů pro tuhle práci musel správce nastavit ručně.

V devatenáctce se počet škáluje sám podle nových parametrů io_min_workers a io_max_workers. Christophe Pettus ze společnosti PGX k tomu ve svém rozboru z 23. dubna 2026 doporučuje správcům, kteří počet nastavovali ručně na osmnáctce, aby to zrušili a vyzkoušeli výchozí hodnoty devatenáctky. Přibyly také parametry io_worker_idle_timeout a io_worker_launch_interval a příkaz EXPLAIN ANALYZE nově umí volbu IO, která ukáže, kolik čtení dotaz opravdu vydal.

Drobnosti, které potěší denní provoz

Seznam dalších změn z oznámení první bety je delší, než se sem vejde. Za zmínku stojí čtyři:

• GROUP BY ALL – místo ručního vypisování všech neagregovaných sloupců stačí jedno slovo.
• WAIT FOR LSN – příkaz, po kterém replika počká, až k ní dorazí konkrétní místo v protokolu změn. Řeší tím starý problém, kdy aplikace zapíše na hlavní server a hned nato čte z repliky data, která tam ještě nedorazila.
• Replikace sekvencí – logická replikace nově přenáší i hodnoty sekvencí, což podle projektu zjednodušuje povýšení verze za provozu.
• Paralelní autovacuum – automatický úklid smí zapřáhnout víc procesů naráz, počet omezuje nový parametr autovacuum_max_parallel_workers.

René Cannaò, zakladatel projektu ProxySQL, označil pro InfoQ za důležitou právě konstrukci WAIT FOR LSN kvůli sladění čtecích replik.

Co beta 2 opravila

Druhá beta je oprava chyb, ne nová funkčnost. Její seznam ale prozrazuje, kde to zatím drhne: mezi opravami je „několik oprav nové vlastnosti grafů podle SQL/PGQ“ a „několik oprav nové syntaxe FOR PORTION OF pro časové tabulky“ (přeloženo). Opraveno bylo i to, že proces příkazu REPACK po havarijním ukončení nezmizel, jak měl.

Beta není vydání

Hodnocení: SQL/PGQ je z uvedených novinek jediná, která mění, co se s databází vůbec dá dělat. Zbytek jsou vylepšení provozu – a právě ta možná rozhodnou o tom, jestli se firmám vyplatí povýšit. Christophe Pettus to pro InfoQ shrnul tak, že změny v devatenáctce, které nejspíš ovlivní chování v provozu, nejsou ty, o kterých se píše v titulcích (přeloženo).

Do produkčního nasazení nicméně vede ještě dlouhá cesta. Beta slouží k testování, projekt sám upozorňuje, že se podrobnosti můžou změnit, a datum ostrého vydání je zatím jen odhad na září či říjen.

Zdroje: oznámení druhé bety PostgreSQL 19 a oznámení první bety od PostgreSQL Global Development Group, rozbor serveru InfoQ, text Christopha Pettuse o asynchronním I/O a dokumentace ke grafům vlastností.