6 ms·
Not critiquing but more curious, why does Postgres seem to get so much love while MariaDB is mostly ignored on HN?
by tapoxi 9y ago
Not critiquing but more curious, why does Postgres seem to get so much love while MariaDB is mostly ignored on HN?
- tsavola 9y agoPostgreSQL gets so much love due to its exceptional quality. Perhaps MariaDB is not of exceptional quality.
- rgbrenner 9y agoMariaDB is a fork of MySQL... which already had its heyday when Postgres was more immature. I've been using Postgres since 7.x (early 2000s) and everyone loved MySQL back then. In fact, the late 90s up to maybe 5-6 years ago, MySQL got more attention than postgres.. that's a long time for any software package. There are a lot of reasons for MySQL sort of losing its position -- from the Oracle takeover, to the fork, to the various compromises that were made early on (that Postgres didn't make)... and together + Postgres continuing to make steady progress during that time, has put Postgres in the lead.
- zeveb 9y agoI don't believe there was ever a time when Postgres was more immature than MySQL. There was a time when hype-driven development was immature enough to prefer MySQL, with its silent data loss & data corruption issues, over Postgres. This was, IIRC, mostly due to performance. It turns out, though, that once one configures MySQL not to lose & corrupt data, it's slower than Postgres. Honestly, Postgres has always been in the lead — it's just that as folks have gained experience, they've discovered that they want a stable, reliable, fast database.
- rgbrenner 9y agowhen hype-driven development was immature enough to prefer MySQL I don't think that's an accurate description. In the 90s computers were _a lot_ slower.. and having the option of putting up with a few warts in exchange for increased performance was a significant advantage over postgres. That early advantage gave them a much larger ecosystem - apps that required MySQL, developers that were familiar with it, etc. It took years for that early advantage to be overcome by postgres.. both by improving Postgres performance, and as computers became faster people were less willing to make the compromises that MySQL provided. I think it's worth acknowledging MySQL's early advantages, and not pretending 15 years of popularity was somehow because people were "immature".
- timc3 9y agoI think MySQL's advantage was that it was installed on some many hosting companies servers (along with PHP) that it became ubiquitous for many. Most DB admins that I knew could see no clear advantage of MySQL when we looked at the details apart from for failover and multi-host uptime has an easier deployment. Disclaimer I have been using PostgreSQL for perhaps 20 years now.
- rgbrenner 9y agoThat's the ecosystem that developed because of MySQL's early performance advantage... that wasn't until later on. The performance issue is actually a core part of MySQL's history. We have to go way back to the early 90s. Back then Postgres didn't use SQL. There was a project called mSQL that created an SQL layer on top of Postgres... but it didn't perform very well on the slow computers of the early 90s. So mSQL created it's own lightweight DBMS to replace Postgres. mSQL was popular in the mid-90s, and it's performance started the creation of that early ecosystem that you're referring to. Later MySQL took mSQL and added more features, had a more liberal/cheaper license, and kept the mSQL API.. and that ecosystem that developed around mSQL continued with MySQL. So the performance advantage that gave MySQL it's lead, began pre-Postgres95 (that added SQL to postgres), that created the ecosystem that kept MySQL popular. When MySQL passed mSQL in popularity in 1997, Postgre95 was a little over a year old, and was just recently renamed to PostgreSQL (while mSQL was about 3 years old at the time). If Postgres was more performant, mSQL would have been based on it, and MySQL probably would have never existed. Instead, by the time Postgres addressed the SQL issue, they were 2 years late, and by the time they addressed the performance issue, they were a few more years late (by the early 00s, IIRC the performance was comparable).. and by then MySQL had cemented its lead in the market.
- justinclift 9y agoKeep in mind that the "performance advantage" MySQL supposedly "had" over PostgreSQL mostly came down to a bad default setting in PG. Back in early PG versions (7.x from memory), the default shared buffers setting value was extremely low, in order to allow PG to "just work" even on very low memory systems. (8MB?) The effect of not changing that from the default was PG then pegging the cpu at 100% (moving stuff into and out of the tiny buffer) with terrible performance. When we raised that default to something reasonable for (at the time) modern systems... our performance magically increased substantially from the perspective of many non-DBAs. Note - The exact details are in the PG email archives if anyone cares enough to look. :)
- mjw1007 9y agoAround 2001 Postgres was more reliable than MySQL and more advanced in many ways, but it did have some odd omissions which made it fair to describe it as immature. For example if you wanted to drop a column you had to create a new table and rename it over the old one.
- deleted 9y ago[deleted]
- ape4 9y agoI prefer Mysql/MariaDB's `show tables` vs Postgres' `\dt`. And other commands. More like sql.
- kuschku 9y agoPostgres has similar SQL commands. Commands that start with \ are shortcuts in the psql client that are translated into SQL commands. You can always use SELECT * FROM pg_tables; and operate on those tables as if it was a normal SQL relation (because it is). Additionally, if you use psql -E, it shows you the SQL it runs for such shortcuts. For \d (Show relations) it runs: SELECT n.nspname as "Schema", c.relname as "Name", CASE c.relkind WHEN 'r' THEN 'table' WHEN 'v' THEN 'view' WHEN 'm' THEN 'materialized view' WHEN 'i' THEN 'index' WHEN 'S' THEN 'sequence' WHEN 's' THEN 'special' WHEN 'f' THEN 'foreign table' END as "Type", pg_catalog.pg_get_userbyid(c.relowner) as "Owner" FROM pg_catalog.pg_class c LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','v','m','S','f','') AND n.nspname <> 'pg_catalog' AND n.nspname <> 'information_schema' AND n.nspname !~ '^pg_toast' AND pg_catalog.pg_table_is_visible(c.oid) ORDER BY 1,2;
- ape4 9y agoGood thing there is a shortcut :) Can you do `alter table` on pg_tables?
- kuschku 9y agopg_tables is a view, which only loads data from a few other internal tables, but you can modify many of them, yes. (And many extensions do that). Specifically, pg_tables is defined as CREATE VIEW pg_tables AS SELECT n.nspname AS schemaname, c.relname AS tablename, pg_get_userbyid(c.relowner) AS tableowner, t.spcname AS tablespace, c.relhasindex AS hasindexes, c.relhasrules AS hasrules, c.relhastriggers AS hastriggers, c.relrowsecurity AS rowsecurity FROM ((pg_class c LEFT JOIN pg_namespace n ON ((n.oid = c.relnamespace))) LEFT JOIN pg_tablespace t ON ((t.oid = c.reltablespace))) WHERE (c.relkind = ANY (ARRAY['r'::"char", 'p'::"char"]));
- pohl 9y agoI'm not in a position to answer your question, but I thought you might be amused to know that there was once a day where a question like yours would have been "why does MySQL get all the attention while PostgreSQL is largely ignored on Slashdot." I probably asked that question on more than one occasion. PostgreSQL was already more capable and mature than MySQL at the time.
- calcifer 9y agoMariaDB has the unfortunate burden of being a drop-in replacement for MySQL which means all the warts, oddities and downright horrifying stuff are still there.
- Finnucane 9y agoWell, all the horrifying stuff, minus Oracle.
- fleetside72 9y agoHere's a couple reasons: - call functions(stored procs) as tables and join to them - regular expressions - order by in your views & functions - order by INSIDE your aggregates - create your own aggregates - make your own window functions - left join on your recursive CTE - put temp tables in your function(stored proc) that you can also call as a table (see above) - lateral joins - filter syntax to do pivots - WITH ORDINALITY - generate_series - dollar quoting - write-able CTE's - arrays - ranges - intervals - jsonb (which can be indexed) 1. transformative/analytic functions 2. huge variety persisted formats 3. ability to store logic in the DB tier and re-use it
- steeleduncan 9y agoBoth are good, but I think the current trend towards postgres is because - postgresql arguably has a wider featureset than mysql/mariadb [1] - recent versions of postgresql have solved many of the issues that used to prohibit adoption (scaling issues, logical replication, etc) - since the Oracle aquisition of mysql and the subsequent mariadb fork, the waters are a little muddied for potential mysql/mariadb adopters with regards to which fork to choose and if that is the mysql fork, whether it will remain free. - postgres is default on heroku [1] https://en.wikipedia.org/wiki/Comparison_of_relational_database_management_systems https://en.wikipedia.org/wiki/Comparison_of_relational_datab...
- StevePerkins 9y agoSome people will hate my summaries here, but: (1) The strength of PostgreSQL is that it offers a extremely Oracle-like experience, for free. (2) The strength of MySQL (and its forks like MariaDB, Percona, Vitess, etc) are much better operational support for clustering, replication, sharding, etc. Conversely, PostgreSQL is harder to take to scale, and MySQL is much more weird and quirky in basic functionality. Industry hype aside, the reality is that the overwhelming number of applications AREN'T very high-scale. They're dealing with gigabytes of data, not terabytes or petabytes. And the professionals who deal with petabytes for a living tend to spend less time chatting on web forums, compared to students and hobbyists and bored line-of-business developers. So it's not too surprising that there's more discussion and more love for the database that's best suited for the scale at which most people operate.
- mixmastamyk 9y ago2 used to be true, but is less and less with every release. Won’t say it is false yet, but PG 10 is getting there. What is still left to do?
- kuschku 9y agoCockroachDB-style "set and forget" clusters. If I can just put a container image into my kubernetes cluster, and set it to auto-scale, and postgres automatically scales depending on load, and it all just magically works, then it’d be perfect. Knowing how well engineered everything else in PGSQL is, I’m sure this is going to happen sooner or later.
- ddorian43 9y agoMysql also doesn't have range-based-sharding (in any external tool that I know). You have to look at CockroachDB(postgresql driver) vs TiDB(mysql driver) unless you want to wait 10 years for that to happen in pg/mysql land.
- Annatar 9y agoBecause MariaDB is based on MySQL which is fundamentally broken: check out how basic SQL doesn‘t work on Youtube. And then there is silent data corruption and six different storage engines because Monty & co. just couldn‘t get the code to deliver decent performance for the generic case. Then there’s the nonexistent OS based authentication and very amateurish database backup capabilities. With all of these „features“, MariaDB is „a recipe for success“. Meanwhile PostgreSQL has always been about reliability and stability and has been getting better and better with every release.
- anarazel 9y agoI don't understand this kind of argument. And I'm about as big a postgres enthusiast as you can get. Both postgres and mysql/mariadb have strengths and weaknesses. In some areas they overlap, in some not. In some areas they're of philosophical nature, in others purely technical. I'm fine with arguing that $pro{je,du}ct is better for most cases. But that doesn't mean the other alternatives have to be denigrated as being pure shit. That's not going to convince anybody that's not already convinced, and stirs um enmity. FWIW, I think both postgres and mysql/mariadb benefit from the competition. Do I think that postgres is overall the better project? Yes. Do I think mysql is shit? No.
- Annatar 9y agoIt's really simple: MySQL / MariaDB do not function correctly for the feature set they supposedly support, while PostgreSQL works correctly for that which it supports and people recognised this eventually, which is thankfully why PostgreSQL is the leading open source relational database management system. There is not much philosophy here: MySQL should have never been used since it's always been busted, and thankfully now it's lost so much market share that it's become all but irrelevant. If you want to build bullet proof, robust systems and don't want or can't afford Oracle, one of PostgreSQL variants is a critical piece for building such a system. I like sleeping through my nights instead of wasting my life away troubleshooting MySQL. How about you?
- anarazel 9y ago