Vlákno názorů k článku Přestaňte už používat MySQL, není to skutečný open source od martinpoljak - Článek je sice informačně zajímavý ale vstupní premisa...

Č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.