@everx, ja koristim oba od kad postoje prilicno ravnopravno u svojim projektima, daleko od toga da je univerzalno jedan bolji od drugog, no gresis znacajno u postavci ... nema veze sa inercijom nego brzinom i use-case, na webu (a to je masovnost, specijalni slucajevi su nebitni ako pricamo o kolicini i popularnosti) je bitna brzina, tu je mysql uvek bio i dalje je absolutni sampion, dalje replikacija na psql-u do "juce" nije radila sto je za bilo kakav ozbiljniji HA setup nono a o resenjima poput drbd-a ne bih ovde, "podrska za kompleksne upite" (bolja podrska sql standarda, ozbiljne stored procedure pisane u vise jezika, gzilion puta bolji optimizer...) su do jaja stvar da se koriste, na zalost, masa (a opet pricamo o masi, kolicini, popularnosti, ne o 0.2% elite) svejedno ne zna da napise kompleksan upit ... a za ove jednostavne web upite koje zna mysql em radi do jaja em radi za red/dva velicine brze od psql-a .. istoriski ..
e sad, vreme prolazi, web vise nije isti kao devedesetih, zahtevi su drugaciji... mysql-ov glavni gazda je otiso (onaj sto je tvrdio da subselect i left join nikad nikom nece trebati kada je pravio mysql i koji nije dozvolio da se uposli ni jedan jedini QA inzenjer jer "testirace to raja dzaba") svojim putem a neki drugi ljudi preuzeli pa sada ako pogledas mysql ima utf8m4 podrsku koja radi brze od psql-a, ima full geospatial podrsku koja radi kao na psql-u (i dalje je mongo brzi od oba ?!?! bem li ga kako), ima podrsku za json kompletniju od psql-a (ladno mysql sada postuje veci % standarda od psql-a), ima group replikaciju (ima sitnih bagova jos da se istrebe ali je to sistem par generacija ispred onoga sto psql danas nudi), ima (najzad) cte, window.. ima najzad dobar optimizer pa moze da proguta i one uzasne upite :D .. jedino gde je psql ostao tata su stored procedure (koliko ja znam ne postoji plan da se to uskoro unapredjuje) i "array" tip (momci iz dev tima tvrde da ce daju svi otkaz ako neko zahteva da se to implementira)...
osmica je izasla "juce" jbg i ima uzasno mnogo core-changes u sebi tako da je ocekivano da ce biti stucanja, tek smo na 8.0.13 ... ono sto su trenutni problemi je 2 bug-a sa mem leak-om (bice to sigurno ispeglano uskoro, posebno sto su izgleda bagovi u nekim bildovima samo u externim bibliotekama ne u mysql-u), "cudno" ponasanje GR na azure platformi (azure ima neke cudne probleme sa network komunikacijom, u 8.0.14 je ubacen workaround da se poveca timeout da se zaobidju problemi sa azurom ali videcemo kako ce to da se pokaze u divljini) i performance hit za sve DDL operacije zbog promene data dictionary sistema... ovo zadnje je super smor nekim korisnicima (kreiranje 2500 tabela koje je trajalo 30-40sec sad moze da traje sat vremena, insert u tabelu bez provere FK traje isto kao i da se FK provera radi i slicno) i pitanje koliko ce moci da se ubrza .. (i dalje je brze nego psql :D samo je mnooogo sporije nego 5.7) .. fora je u tome sto je sada ceo data dictionary ACID compliant tako da se sve promene nad strukturom baze rade transakciski (pre 8.0 nisi mogao da rollback neki alter table na primer) i jbg kad predjes sa nontrans na transakcioni sistem za cuvanje cega god, versioning, isolation .!. palac .. mora da izgubis performanse ...
mislim da ono sto je doktora ovde zakacilo je pre default config nego ovih par memlikova koji postoje jer su default setovanja za 5.x mnoooooooooooooogo skromnija od default setovanja za 8.x (ono tipa 2 reda velicine skromnija, 4M vs 128M i slicno) ... ako ovaj config koji sam ja poslao nije dovoljno limitirao ram usage moze to jos da se kasapi :D