Názory k článku Přestaňte už používat MySQL, není to skutečný open source

Síce sám Oracle a MySQL nemusím, ale tento článok dosť znie ako PR, hlavne keď hneď prvá veta tlačí "používajte MariaDB" a iné alternatívy ani nespomína. Áno, je to odnož MySQL, ale nie je to jediná DB, ktorá plnohodnotne nahradí MySQL a má transparentný vývoj.

Článek "tlačí" uživatele na jakoukoli jinou databázi než MySQL. Chce to si to přečíst celé.

Ubisoft MariaDB rozhodně doporučuje. Neztratila žádná data, ba právě naopak.

"ba právě naopak." znamená, že mají v DB víc dat, než by měli mít?

Mají víc záloh než by měli mít.

Ba právě naopak znamená, že data ztratili?

Ine alternativy spomina.

Pokud používáte vlastní aplikace a máte svobodu provádět změny v tom, jak a jaká databáze se používá, existují desítky vyspělých a dobře fungujících open-source databází, z nichž si můžete vybrat, přičemž nejoblíbenější obecně používanou databází je PostgreSQL.

Tady jde hlavne o stare aplikace, kde muze byt migrace na cokoliv jineho nez MariaDB problematicka. Asi nikdo pri smyslech nebude rozjizdet novy projekt na MySQL.

Pokud vám záleží na podpoře open source softwaru a v roce 2026 stále používáte MySQL, měli byste přejít na PostgreSQL.
Kto je autor? Redakce?

Doporučeno je na cestě od nadpisu na homepage směrem diskusi pod článkem nevynechat hentý oný mezikrok spočívající v rozkliknutí článku.

Áno presne vás som tipoval. A po prvej vete som vedel že nemá zmysel čítať ďalej. Ale diskusia bude výživná a to sa tiež počíta.

Pokud jsem četl dobře, tak autorem není David a jedná se o překlad cizího článku.

Ani po upozornění jste si článek zjevně nepřečetl, a pokračujete v moralizování. Obvykle nemám potřebu Davida Ježka hájit, ale teď se chováte jako naprostý pitomec vy.

Skutocne nemienim citat o tom ci 2 + 2 = 7 alebo 6 lebo 6 je blizsie vysledku. MySQL ani nic co z toho vzniklo databazou nikdy nebolo rovnako ako webovy lepic kodu nikdy nebude programator. Ale ja mam iny svet.
Vo vysledku by som aj tak rad vedel kto to prelozit a kto vybral prave tento clanok na preklad.

"Velká část uživatelů MySQL přešla na MariaDB již v polovině desátých let, "

Tady je urcite chyba - mariadb byla releasnuta 2009 - takze by se mohlo uvozovat spis o roce 2015 nez 1995.

Vloni Oracle bez vetsiho vysvetleni zredukoval vyvojovy tym MySQL. U MariaDB doslo ke generacni obmene managementu - navic probehly zpravy, ze MariaDB na tom financne neni nejlepe. Takze se letos do toho zkouseji oprit.

Na MySQL porad jede (a pojede) mraky aplikaci. Postgres ma vyhodu v diverzifikovanem vyvoji - tady se ukazuje urcita vyhoda BSD licence, diky ktere vznika vyssi mnozstvi specializovanych forku - z nich se do Postgresu vraci minimum nebo nula. Existuje ale neprimy benefit - s vyvojem Postgresu ma nejakou zkusenost nasobne vic vyvojaru nez s MySQL. Coz v dobach jako je dneska, kdy je nouze o finance vyhoda - distribuovany vyvoj se snaz ufinancuje

Na Postgresu bezproblemove bezi v CR Aukro, nebo Fortuna (o kterych neco vim), takze z hlediska zateze a provozu Postgres urcite dokaze zastoupit MySQL. Nicmene na kazda aplikace je portovatelna do Postgresu. Postgres ma rad dobre znormalizovane databaze. Naopak databaze s hodne sirokymi tabulkami s velkym poctem indexu navic casto updatovane zvlada podstatne lepe MySQL.

ono v originale je to "switched to MariaDB already in the mid-2010s", takze to odpovida spis tomu roku 2015 - myslim ze jen trochu nesikovny preklad (ale nenapada me jednoslovna alternativa v cestine)

desátých nikoli devadesátých

Kde vidíte tu chybu? Polovina desátých let je 2015... Nejspíše jste to jen špatně přečetl jako "devadesátých", ale když už postuje o chybách a text ještě citujete, bylo by dobré ho, jak nás učili už v první třídě, číst a nehádat.

Mate pravdu - četl jsem devadesátý - omlouvám se.

Taky jsem se nachytal...

Inu se zkracovanim na dvouciferne vyjadreni roku vzdy problemy :-)

Pořád lepší zkracování na dvě cifry s tím, že století je určeno kontextem než bohužel oblíbené: "v roce dva dvacet šest" a mluvčí myslí 2026, přitom nikdy neřekne "jedna devadesát tři"

Také jsem četl devadesátých, asi zvyk. S pojmem desátých let se střetávám poprvé. :D

No a jak bys označil jednoslovně období 2010 až 2019? Máš dvacátá, třicátá až devadesátá... Tak potřebuješ i desáta. Jen s tím první desetiletím je to komplikované ;) .

Pro první desetiletí se používá název nultá léta. Je to celkem logicky pokryté celé.

Nemyslel jsem to tak že neznám ten pojem, ale že jsem ho ještě nikde nečetl použitý. Vždy se psalo devedesátá, proto ten zvyk a špatné přečtení.

desátých != devadesátých

"z hlediska zateze a provozu Postgres urcite dokaze zastoupit MySQL" - tohle bohužel není pravda. Dodnes má MySQL (a MariaDB) při použití InnoDB mnohem lepší výkon pro aplikace které hodně mění data a Postgres u nich musí spouštět vacuum (při spuštění dochází k výraznému poklesu výkonu). Další podstatný rozdíl je v tom, jak Postgres (ne)zvládá spousty paralelních session, díky tomu že pro každou session spouští vlastní proces. Neprojevuje se to u každé aplikace, ale ty které jsou postižené a nemohou změnit svou architekturu bohužel musí Postgres opouštět.

Paralelních session můžete mít otevřených tisíce - v tom problém není. Problém je v tom, že v každé session můžete pustit dotaz, který se okamžitě začne vykonávat (bez jakékoliv fronty) - a tím si můžete úplně utavit server. Běžně se to řeší nasazením pgbounceru v transakčním módu - a nebývají s tím problémy.

Postgres není dobrá databáze na data, kde dochází k intenzivním změnám relativně malého počtu řádek navíc v rámci jedné transakce (je menší zlo udělat 10 změn na 100 řádcích než 100 změn na 10 řádcích). VACUUM vždy běží až po dokončení transakce. Co je problém - a kde je Postgres výrazně pomalejší než MySQL jsou updaty oindexovaných sloupců. Ve své praxi jsem se za poslední roky nesetkal s tím, že by VACUUM byl problém (pokud si někdo nevypne autovacuum).

Horší je, že pokud se nepoužije hotupdate, tak postgres kromě modifikace samotne tabulky přidává reference do všech indexů - i do těch, které se nezměnily - což u MySQL se neděje. Tam se sekundární indexy odkazují na index PK - a je to výrazně efektivnější. Což byl třeba problém, kvůli kterému Uber odešel z Postgresu. Už jsem to tu zmiňoval - pokud máte tabulku, která má mnoho oindexovaných sloupců (bavíme se například o vyšších desítkách nebo nižších stovkách), tak UPDATE bude na MySQL výrazně rychlejší. Nemůže za to VACUUM, ale to jak má Postgres navržené indexy.

14. 1. 2026, 12:57 editováno autorem komentáře

A také jde, pochopitelně, o intenzitu provozu. Už v řádech nižších tisíců TPS je rozdíl znatelný (resp. násobný) i při jednotkách indexů.

Jedna věc je rozpoznatelnost rozdílu v syntetickém benchmarku, druhá věc je použitelnost resp nepoužitelnost v praxi. Shodou okolností nedávno o tomto problému vyšel příspěvek na blogu https://www.depesz.com/2026/01/06/what-is-index-overhead-on-writes/

Design, který používá InnoDB zrychluje update (zvlášť přez PK) a SELECT (přes PK), ale na druhou stranu zpomaluje jiné operace - a to docela výrazně.

Dalším faktorem jsou síťové latence a režie protokolu. Pokud aplikace neběží lokálně - tak režie TCP bude určitě vyšší než režie indexů v Postgresu (pro jednotky indexů). U některých aplikací síťové latence jsou zásadní problém - a je úplně jedno, jestli je db Oracle, Postgres, MySQL nebo MSSQL.

Nikdy jsem ale netvrdil, a nebudu tvrdit, že Postgres je ideální databáze do které jde přeportovat libovolná aplikace. Ve výsledku může být ideální kombo Postgres, MySQL, redis, elastic, mongo - vždy budou určité typy zátěže, kde nějaká databáze bude excelovat a jiná na tom bude o dost hůře - a při větší zátěži se vyplatí ty databáze kombinovat.

14. 1. 2026, 15:09 editováno autorem komentáře

Mnoho Linuxových administrátorů si asi všimlo, že MySQL se před lety z oficiálních repozitářů většiny distribucí postupně vytratila a byla nahrazena MariaDB. Pokud někdo chtěl používat MySQL Community Edition, nezbylo mu než sáhnout po oficiálním repozitáři od Oracle.

V poslední době mi ale přijde, že se MySQL Community Edition znovu objevuje v repozitářích řady známých distribucí. Proč k tomu došlo, si nejsem úplně jistý — tipuju, že prostě proto, že ji část uživatelů stále chce a aktivně používá. Ať už kvůli kompatibilitě, zvyku, nebo konkrétním vlastnostem.

Nedávno jsem si navíc hrál s UnixODBC drivery od MariaDB i MySQL a z praktického pohledu je kompatibilita pořád velmi slušná. V běžných scénářích rozdíl skoro nepoznáte, což ostatně jen potvrzuje, jak blízko si tyhle dva světy pořád jsou — minimálně na úrovni klientů a rozhraní.

14. 1. 2026, 09:41 editováno autorem komentáře

Co se vlastností týká, nějakou dobu zpátky jsem koukala po podpoře JSON v relačních databázích (potřebovala jsem ukládat složitější JSON objekty, které by bylo prakticky nemožné reprezentovat jako tabulky, ale nechtělo se mi sahat po NoSQL)

PostgreSQL má skvělou podporu, včetně indexování a queries pomocí jsonpath, MySQL je na tom taky slušně... A v MariaDB je JSON prakticky jen varchar s validací při insertu.

14. 1. 2026, 10:13 editováno autorem komentáře

No, ono je nejlepší to jako ten varchar s nějakou validací brát i v tom PostgreSQL. Dotazování i v JSONB je spíš z nouze ctnost, protože aspoň moje zkušenost je, že se ty dotazy prostě píšou blbě a je třeba řešit různé casty, možnou absenci záznamu apod.

Ale mít u tabulek sloupeček var pro flexibilní ukládání ostatních, dopředu těžko předvídatelných dat je praktický postup. Postupně se z toho JSONu vytahují relevantní záznamy a dávají do sloupečků dle potřeby, ale ta data tam už historicky jsou a dá se s nimi něco dělat. Např. při JSON odpovědích z nějakého API tak ten JSON můžu jednoduše uložit a nemusím ho kompletně rozpadnout, když v tuto chvíli potřebuju jen nějakou část.

Zajímavé, mně to fungovalo dobře a nenarazila jsem na problém, ale třeba jsme po tom chtěli něco jiného.

Jinak v mém případě šlo o ukládání <a hned="https:/­/www.hl7.org/fhir/">FHIR resources, a tam je to kvůli komplexitě docela těžké rozpadnout do tabulky, zvlášť když se v průběhu mění potřeby filtrace záznamů.

Jinak jedno z úskalí json jako stringu je že `{"a": "b" ; "c": "d"}` != `{"c": "d"; "a": "b"}`

Já jsem MariaDB opustil v době, kdy se rozhojnila potřeba používat JSON typ a určité funkce, protože to tam nešlo, nebo to bylo značně pomalé. Asi bych tomu zase mohl dát šanci, ale u MySQL si nemám zatím vůbec nač stěžovat.

Taky jsem mel ze spravy MySQL Oraclem strach, ze ho pohrbi, a zatim se tak nestalo. Ale koukam, ze to ted nevypada s budoucnosti MySQL dobre. Mne se libi, ze k tomu dodavaji treba prostredi MySQL WorkBench, proste nepripadne mne to spatny. Na druhou stagnace vyvoje nevesti nic dobreho. Necham se prekvapit co bude dal.

Pořád je to problém korporátní vs komunitní open-source. Tohle byl problém už v dobách MySQL AB, kterou Widenius bez rozpaků střelil Sunu. A nikde není záruka, že to nezkusí znovu s MariaDB. Což je důvod, proč nechci ani jedno. To mi byl milejší ten fork od Percony, ale už nevím, jestli ještě běží (Zaitsev se teď už asi taky víc věnuje PostgresSQL).

Článek je sice informačně zajímavý ale vstupní premisa jako taková je nesmyslná. MySQL samozřejmě je open source. Je source open? Je, takže to je open source. Že je ten projekt špatně vedený, komunitní vývoj v podstatě nefunguje a Oracle to zcela nepřekvapivě agresivně monetizuje a jinak zabíjí je sice politováníhodné, ale s tím, jestli jde o open source projekt nebo nejde to nesouvisí.

On predevsim zadnyho "uzivatele" henten opensource ... naprosto nezajima.

Zajimajiho ho naklady a prinosy. Pokud nekomu neco 30+let jede na MySQL, tak naprosto logicky nevidi naprosto zadnej duvod k tomu, aby to migroval na mariu (natoz nekam jinam) a potazmo resil nejakou nekompatabilitu. Proc by to jako mel probuh delat?

A pokud tu nekdo zminuje PostgreSQL, tak by me zajimalo, kolikrat na tom delal upgrade verze ... protoze se vpodstate pokazdy neco podela a je treba neco resit ...

Migrací Postgresu jsem dělal stovky - od dob, kdy se začal používat pg_upgrade, upgrade samotný vždy prošel bez problémů. V posledních letech jsem viděl u zákazníků bezproblémové přechody z 15-16, 16-17, a teď nedávno z 17-18. Neviděl jsem, že by se upgrade podělal.

Viděl jsem, že s novějšími verzemi některé aplikace pro monitoring měly problém - dochází ke změnám systémového katalogu a bez podpory novější verze to samosebou failne. Dnes už spíš výjimečně se narazí na nějaké problémy s kompatibilitou - vzpomínám na přechod na ANSI stringy nebo změna formátu bytea. Téměř vždy se objeví nějaké důsledky práce na optimalizátoru - pár dotazů v aplikaci se chová jinak - pár je rychlejších, pár je pomalejších. Dost problémů je způsobeno tím, že uživatelé po upgrade nepustí ANALYZE. To se dělo hodně kolem 10-12. Měnila se optimalizace CTE, zaváděl se JIT. To se stát může - zvlášť u dotazů, kde jsou špatné odhady. Nicméně rozhodně se to nestává pokaždé - a problémy s optimalizací vám mohou nastat i v provozu nárůstem tabulek (nebo po přidání indexu).

To ale není specifikum Postgresu - to platí pro každou databázi, která negarantuje 100% zpětnou kompatibilitu u optimalizace. U MySQL v 8čkové verzi došlo k razantnímu přepisu optimalizátoru - tam problémů s dotazy muselo být mraky. A co se dívám na release notes MySQL i MariaDB, tak optimalizaci dělají dost změn a dost pochybuju, že by garantovali neměnnost plánů. Jak MySQL tak MariaDB má nyní optimalizaci podobnou Postgresu - u složitějších dotazů dostanete lepší plány - na druhou stranu tam bude vyšší citlivost na statistiky. A ten přepis optimalizace museli udělat, protože ve starších verzích MySQL optimalizace složitějších dotazů nebyla dobrá.

15. 1. 2026, 06:16 editováno autorem komentáře

Jen je upgrade trochu pain ve chvíli kdy postgres běží v kontejneru.

Jak se upgrade postgresu v containeru liší od běžného? Vždyť to nemá s dockerem nic společného.

No vidis, ja tech migraci mam rekneme desitky a minimalne v 50% pripadech musim resit, ze to neprojde. A naprosto typicky pak dohledam ze je treba nekde spustit nejakej alter na cosi, coz bych od funkcni databaze cekal, ze si udela sama kdyz se vi ze to je treba ...

Provozujeme stovky instancí PostgresSQL u klientů a problémy při upgradu obecně nejsou. Rozhodně s upgradem MariaDb je těch problémů mnohem víc. Ne že by snad samotná databáze po upgradu nefungovala či ztratila data, ale změní svoje chování a se stejným nastavením se začně chovat jinak, což má typicky vliv na výkon některých query a někdy i na výsledky. Vyřešit lze někdy úpravou konfigurace, ale častěji je potřeba upravit query v aplikaci. PostgreSQL je v tomhle konziistentní a nepamatuju si, že by upgrade ( i přes několik major verzí ) způsobil podobné chování.

Asi jediná past u PostgreSQL, co si vybavuju, nesouvisí ani tak s upgradem databáze jako toho okolo. Po změně verze glibc je potřeba udělat refresh collation. Na to když se zapomene, tak to umí řádně pozlobit. V dokumentaci je to samozřejmě napsané, ale vývojáři naštěstí ( od verze 15? ) přidali warning po příhlášení do databáze, což je fajn.

Do budoucna je asi lepší přejít na libicu. V některých případech může být nezbytná reindexace i s libicu, ale detekce jestli je nebo není reindexace nutná je na libicu nativní, kdežto na glibc je to spíš workaround.

Mluvis predpokladam o tomhle:

"
The database was created using collation version 2.40, but the operating system provides version 2.41
Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION
"

To je taky znamka uzasnyho pristupu ... proc si to kua neudelaj ... a to ani (jak je vidno) u systemovy databaze...

Nevím, co myslíte systémovou databází? Postgres žádnou systémovou databázi nemá.

Tohle má historické pozadí - Postgres je databáze navržená primárně pro Unix a Unix má integrovanou podporu collation v knihovně libc - tady jde o primárně o řazení. Nicméně se ukázalo (a to relativně pozdě - ani ne 10 let zpátky), že implementace těchto řadících algoritmů není stabilní. Což samozřejmě vede k riziku curruptnutí indexu. A když už jsem u historického pozadí - je to databáze z US, do které se podpora 8bit kódování dodělávala hodně pozdě, a nikomu v té době nedocvaklo, jaké problémy s glibc mohou nastat - libicu ještě neexistovala - a implementace vlastní podpory collations ve stylu MySQL se zdála šílenost - když byla podpora v libc (v POSIXu).

Nicméně vlastní implementace collation také není absolutní řešení. Jakmile jednou vydáte nějaké collation - už ho nemůžete fixnout. Můj první patch paradoxně nebyl do Postgresu, ale do MySQL - opravovali jsme řazení pro češtinu. Mám pocit, že nikdy nebylo commitnuté - právě, že byl potřeba rebuild indexů.

Ten ALTER můžete dělat až po rebuildu indexů - ne dříve. A rebuild indexů může být dost zdlouhavá záležitost - nic co byste chtěli, aby systém udělal automaticky. Navíc tohle může být také falešný alarm - glibc nemá sémantické verzování collations, takže je na vás abyste se rozhodl - jestli budete reindexovat nebo to ignorovat.

V tom je lepší libicu, která má sémantické verzování pro collation - takže už nedojde k falešným alarmům. Bohužel - realita je taková, že collation nemůže být neměnné - dochází k opravám, mění se normy, ... Jediné 100% immutable colllation bude C, případně C UTF8, tam by tento problém neměl nastat.

Tohle je jeden z důvodů proč není ideální dělat naráz upgrade Postgresu a upgrade operačního systému. A pokud lidi nemají trochu znalosti, tak pak jsou překvapení. Nicméně ten problém s glibc je relativně nový, a když se to poprvé objevilo, tak všichni byli hodně špatní - teprve pak se tam přidaly kontroly na které narážíte -- mohou tam být maximálně 5 let - předtím mohlo dojít k tichému poškození indexů :-/ a nikdo nechápal, proč.

Pojem open source je dnes širší, nejde jen o licenci a dostupnost kódu, ale též o komunitní řízení projektu, které zaručuje nejen otevřený kód, ale též otevřený vývoj. V článku to je krásně popsáno a pasuje to na řadu dalších korporátů, které opensource podporu jen markýrují.

https://almaer.com/blog/community-driven-open-source
https://www.cmswire.com/cms/enterprise-cms/nuxeo-vs-alfresco-how-do-you-like-your-oss-001254.php

14. 1. 2026, 17:44 editováno autorem komentáře

Ne, nejde. Open source je prostě projekt s otevřeným kódem. Nemusí být ani komunitě vyvíjený a dokonce ani dostupný zdarma. Cokoliv jiného je nesmysl.

Ten článek by mohl používat termín třeba opensource komunitní projekt. Asi na to není zavedený žádný ustálený pojem, ale bylo by ho potřeba - včetně nějaké metriky, která by hodnotila kvalitu vedení projektu. Opensource sám o sobě není ještě zárukou benefitů, které dnes často (ne zcela správně) s pojmem opensource spojujeme.