Znáte to, když sedíte u piva s kamarádem vývojářem a on poví: „Vím, že to zní blbě, ale WordPress databáze je vlastně jenom stará dobrá tabulka v Excelu, která se rozrostla do nesmírných rozměrů.“ A má pravdu. wp_posts, wp_postmeta, wp_options — to všechno jsou jen řádky a sloupce, které MySQL (nebo MariaDB) plácá na disk už od roku 2003.
Ale co když se to má změnit dřív, než stihnete říct „migrace“?
V komunitě se už nějakou dobu šepotá o SQLite podpoře v jádru WordPressu. Ne, není to legrace. Gutenberg Phase 3 (spolupráce a workflow) přináší požadavky, které klasický klient-server model MySQL řeší krkolomě. Představte si: lokální vývoj bez Dockeru, testování v CI/CD bez nastavování databázového serveru, dokonce i běh WordPressu na edge serverech u Cloudflare Workers nebo Vercel.
„SQLite v jádru WordPressu není otázkou jestli, ale kdy. A odpověď zní: dřív, než si myslíte.“ — příspěvek v make.wordpress.org/core, listopad 2024
Proč to vlastně řešit? Máme přece MySQL a funguje to.
Funguje. Dokud nefunguje. Každý, kdo kdy migroval web z shared hostingu na VPS, zná bolest: „Error establishing a database connection“. Nebo ten moment, kdy wp_options má 50 000 řádků, protože nějaký plugin si tam ukládal cache, a web se načítá 8 sekund.
SQLite by řešil několik věcí najednou:
- Zero-config vývoj: Stáhnete WordPress, spustíte
php -S localhost:8000a běží. Žádný Docker, žádný MySQL container, žádné „nejdřív spusť databázi“. - Atomické nasazení: Databáze je soubor. Kopírujete ho jako jakýkoli jiný asset. Žádný
mysqldump, žádné zamknutí tabulek. - Edge-ready: SQLite běhá v paměti, žádné síťové hop-y k databázovému serveru. Pro headless WordPress (kde frontend běhá jinde) je to game-changer.
Ale pozor — není to jen o SQLite
Paralelně se rodí WordPress Playground — běh WordPressu přímo v prohlížeči přes WebAssembly. Ano, čtete správně: WordPress v PHP zkompilovaném do WASM, s SQLite v paměti prohlížeče. Můžete si vyzkoušet pluginy, témata, dokonce i Gutenberg bloky, aniž byste nainstalovali cokoliv. Jde o playground.wordpress.net — zkuste to, je to šílené.
Co to znamená pro vás, majitele webu? Tři věci:
- Pluginové ekosystém se musí přizpůsobit. Pluginy, které předpokládají MySQL-specifické funkce (
FULLTEXTindexy, uložené procedury, specifické datové typy), budou muset psát abstraktní vrstvu. Už dnes vidíme první „SQLite-kompatibilní“ značky v repozitáři. - Hosting se změní. Shared hostingy, které dnes prodávají „WordPress hosting“ jako MySQL + PHP, budou muset nabídnout i SQLite variantu. Nebo zemřou. Už teď někteří (např. Kinsta, WP Engine) experimentují s vlastními databázovými vrstvami.
- Migrace budou zábavnější. Přesun z MySQL na SQLite (a zpět) nebude kliknutí na tlačítko. Bude to vyžadovat konverzi dat, testování, možná i přepsání některých dotazů.
Kuriózita z komunity: Když plugin vytvořil 200 tabulek
Loni na WordCampu v Praze vyprávěl jeden senior vývojář příběh: klientský web měl 200+ tabulek v databázi. Příčina? Plugin pro formuláře, který pro každý odeslaný formulář vytvořil vlastní tabulku. Ne řádek. Tabulku. 15 000 formulářů = 15 000 tabulek. MySQL to zvládlo, ale SHOW TABLES trvalo 12 sekund.
S SQLite by to bylo ještě vtipnější — každá tabulka je soubor v systému souborů. 15 000 souborů v jednom adresáři? Dobrý večer, filesystem.
Co s tím teď? (Kromě paniky)
Nic nehorí. MySQL/MariaDB nezmizí zítřek. WordPress je slavný svou zárukou zpětné kompatibility — wpdb třída abstrahuje databázový driver už roky. Ale trend je jasný: budoucnost je v přenositelnosti dat.
Pokud spravujete web sami, začněte myslet o tom, co vaše pluginy dělají s databází. Máte přehled o tom, která tabulka k čemu slouží? Kdy jste naposledy čistili wp_postmeta od orphaned záznamů? Víte, který plugin přidává 50 řádků do wp_options při každém načtení adminu?
Tyto otázky dnes zní jako „technické detaily“. Za rok-dva budou rozdílem mezi webem, který migruje hladce, a webem, který vám padne v nejhorším možném momentě — třeba v čtvrtek poledne, když chcete jet na víkend.
Zdroje: WordPress Core Blog, WordPress Playground, SQLite Database Driver PR, diskuze na WordCamp Prague 2024.