The guy has deliberately changed a default setting (sql_mode) to make MariaDB/MySQL look worse. When someone pointed that out in the comments, he left it unresponded. Which is already telling something about PostgreSQL evangelism.
Speaking of comparing MySQL and PostgreSQL functionality, I've been spending some time recently on this very topic. Both are great databases with interesting and sometimes unique features. Here are some of the features PostgreSQL is missing as compared to MySQL:
- synchronous multi-master cluster (Galera, Group Replication)
- distributed in-memory grid with automatic sharding (NDB)
- semi-synchronous replication (will be available in PostgreSQL 10)
- built-in logical replication (will be available in PostgreSQL 10)
- built-in event scheduler
- clustered indexes
- declarative partitioning (limited functionality will be available in PostgreSQL 10)
- optimizer hints
- optimizer tracing
- efficient MVCC implementation that is unaffected by XID wraparound problems and VACUUM issues (see also Uber's report on moving from PostgreSQL to MySQL)
- page-level compression
- page-level encryption
- page-level incremental backups
- user variables
- NoSQL client APIs (HandlerSocket, memcached protocol, X protocol)
- virtual columns
- ability to choose data page size on database creation
- ability to specify column order when adding a new column with ALTER TABLE
- write-optimized storage engines similar to MyRocks and TokuDB
All of that may seem small from a developer's standpoint. Those things, however, are huge for people who design and operate the busiest websites on the internet. Which is probably why MySQL still shines in that field.
Advanced replication strategies in MySQL and Oracle mostly cause hair loss and divorce. Everywhere I have worked that uses these databases eventually convinces itself that it needs futuristic replication technology and then goes on to suffer from outages and weird corruption. It turns out, distributed consistency is a hard problem. Oracle and MySQL both benefit monetarily from people assuming it will work and then activating it, only to find out a month or two later that it's a complicated problem that requires actual planning and oversight.
I think Postgres will be a better product when it incorporates similar functionality, but the implementations in MySQL and Oracle lie somewhere on the border between false advertising and reckless endangerment. I appreciate that Postgres not having it as two-lines of configuration sends a message that you are making a commitment. Nearly everything else in Postgres is set-it-and-forget-it. You really want to have a DBA if you're going to try to make replication work. When you read the docs on having a hot standby and how much of a commitment that is and sense yourself getting tired, you're starting to appreciate what you might be getting yourself into with single-master replication, let alone multi-master.
> The guy has deliberately changed a default setting (strict_mode) to make MariaDB/MySQL look worse. When someone pointed that out in the comments, he left it unresponded.
I don't think the comments read like that. Someone pointed out that some MySQL variants have changed the default in a recent version and the author criticised the defaults, so the implication is that he wasn't using a bleeding-edge MySQL installation and got the previous defaults.
> - synchronous multi-master cluster (Galera, Group Replication)
Which doesn't work, see [1]. What other features of those you listed the authors claim that work, and just don't when you look deeper?
Lot of the big companies are using MySQL as a NoSQL database, and that's not a bad way to use MySQL, but it's a pretty bad relational database, see [2].
I didn't realise a few of these existed, so thanks.
> - page-level encryption
This got me excited, but for anyone else looking: to keep the key securely (not in a file on the DB server, where an attacker can get it + the DB files) you need to but MySQL Enterprise Edition. Quoting from https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-en...:
> The InnoDB tablespace encryption feature in non-enterprise editions of MySQL uses the keyring_file plugin for encryption key management, which is not intended as a regulatory compliance solution. Security standards such as PCI, FIPS, and others require use of key management systems to secure, manage, and protect encryption keys in key vaults or hardware security modules (HSMs).
Well, personally what I see is people comparing a group of developers that are adamant on never corrupting any data, where everything is secondary and will refuse to push any feature that may cause problems with a group that is adamant on increasing market share, if it's by doing a low quality MVP so be it, that I have seen corrupting data on production several times, and whose software still carries the scars from those MVP's errors.
Yes, MySQL is all featureful¹. The only thing missing there is guarantees that your data will stay good.
1 - Some of those are "no, we won't ever implement it" features that will do nothing but eat your data by design. Why would you ever want them in a persistence layer? Cache on memory somewhere better.
MySQL has similar issues to postgres vacuum. If 'checkpoint age' gets too high throughput drops by ~5x to prevent WAL wrapping. We hit this in production when using 5.5. They've made a lot of improvements to flushing in recent versions, but it isn't a strict advantage. With both DBs as long as you monitor you would be fine.
Not sure of your other points, i have no need for them.
What i really don't like on MySQL (and i don't care for a lot of other stuff): MySQL 5.6 (yeah don't forget your version numbers) really sucks for queries with or.
It sucks to write 2 selects with an union which is 100x faster than the same query with one select and ONE or.
I have been curious to ask someone who is knowledgeable about databases/MySQL: Spanner has a feature for creating interleaved tables, which helps data locality when performing joins on a distributed database. [1] Is this an important feature for a large database, and does MySQL provide anything similar?
This is really about database semantics. If you think database semantics matter, you'll almost certainly prefer postgres.
A lot of people simply don't care about database semantics though. Possible reasons:
* They are more interested in a particular application (e.g. wordpress), and use whatever default database it seems to prefer.
* They are more interested in a particular framework/library (e.g. django), and use whatever database it seems to prefer.
* They don't see any reason a database should have interesting semantics, because it's just a place to stash data until you need it again.
* They really care about programming languages, but see SQL as a second-class citizen that looks archaic and is really just an obstacle to work around using cool language features.
I believe database semantics do matter. It's hard to make a single argument that will convince everyone, but here are a couple things to consider:
* SQL catches errors that may be impractical to catch even with haskell. For instance: you could have had a bug in the application three versions ago that lead to an inconsistent database state (e.g. a duplicated item ID), and you are just finding the bug now. SQL to the rescue: if the unique constraint exists, then you are fine, and the error would have been raised three versions ago before it ever got in the database.
* Few languages have anything that comes close to ROLLBACK. Erlang kind of does, in the sense that it's a mostly-functional language and a process crash mostly resets you to a good state. But the guarantees of ROLLBACK are much stronger and clearer. I believe this is actually why erlang never really took off widely -- a PHP script hitting the database is a better version of the same concept: the PHP code can crash, and that will cause a lost connection and a ROLLBACK in the database, getting you back to a known-good state and the other requests just continue working (security and other PHP jokes aside).
Rambling a bit, but I believe postgres really is the leader when it comes to database semantics, and I believe that is one of its most important contributions.
> I believe this is actually why erlang never really took off widely -- a PHP script hitting the database is a better version of the same concept: the PHP code can crash, and that will cause a lost connection and a ROLLBACK in the database, getting you back to a known-good state and the other requests just continue working (security and other PHP jokes aside).
Comparing Erlang to PHP + transactional DB is regrettable.
Firstly, Erlang's "let it crash" philosophy, together with its sophisticated supervisor/worker framework, aims for resilience in the face of failure due to bugs or bad data. A PHP script hitting a database may be a better design for a simple web application, but it is in no way superior to the Erlang/OTP ecosystem for Erlang's primary use case: soft real-time, highly concurrent, resilient and robust systems. It cannot reasonably be compared to a scripting language + DB, nor does it make any sense to.
Secondly, Erlang is also able to work with transactional databases, from its built-in Mnesia DBMS to Postgres and more. A more appropriate comparison would be between Erlang + DB vs PHP + DB, and then I think you will agree that Erlang would generally fare better than PHP in that case.
WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres.
Finally, claiming that Erlang didn't take off because it lacked the transactional semantics of PHP + DB does not compute, because I never saw any claim that Erlang offers transactional DB semantics (unless it happens to be using a transactional DB).
You can't compare SQL to Haskell like that. There are multiple b-tree implementations for Haskell that of course will not allow you to insert duplicate keys.
There is even a real relational database system in Haskell that actually obeys the laws relational algebra, unlike SQL.
We use Postgres over MariaDB/MySQL because of working CHECK constraints, Common Table Expressions, extension support, JSON support, custom types and its great documentation.
There's an alarming list of behavior MySQL got negligently wrong at some point. That code is mostly still present (you can't prevent a client from enabling it!) and I have to assume some of the maintainers who thought it was reasonable are still involved.
And not everything on the list has a fix available. Off the top of my head, there are still broken storage engines that can't rollback, not all of them can be disabled, and STRICT_ALL_TABLES won't stop you from writing to them. Some foreign key constraints are supported while others are parsed and then silently ignored.
Maintainers often have a perspective that rates backward compatibility higher priority than an individual user would. Even if they have learned from previous mistakes in policy or implementation.
I've used Postgres for years because it's sane out of the box. I know you can configure MySQL to mitigate these issues and use InnoDB by default, but the mere presence of data-destroying features is a red flag to me.
I know I could put the logic in my application, but I like the certainty that comes with knowing what I put in is what I get out.
I do recommend to read through the PGSQL manual (thick PDF file but you can work through the important parts in a week), it's a joy to read compared to the MySQL one.
Postgres supports a sophisticated full text search featureset while mysql does not. Implementing full text search on Postgres is not that difficult and can prove to be a much cheaper alternative to Elastic Search up to a certain scale. This was a major reason for me to recently pick Postgres over any other storage technology.
I use PostgreSQL but are not sure it was the right choice. In MySQL it is easy to set which collation to use for a query to get the correct order in the users language when using order by. In PostgreSQL it depends on the locales installed on the OS making it much harder to get a correct order by and requires more work when setting up the servers
For me, personally, it was because, until very recently (July 2017) PostgreSQL had CTEs and window functions and MySQL did not. I worked on small/medium size apps so performance wasn't an issue and having these features made my life easier as a developer.
In MariaDB 10.2 and MySQL 5.7 and above, this wouldn't happen. It's FUD. The sql_mode, and mysql/mariadb version is not specified.
This seems purposefully contrived; just another developer who throws their toys out of the pram, because they don't read the documentation and just expect software to work for them.
If anything the author has done nothing more than demonstrate ignorance, malice, or both.
When choosing a database, of any kind, you are choosing where to store precious data! Read the fine manual!
MariaDB, MySQL, PostgreSQL, and even the likes of MongoDB offer so many diverse options and storage formats and retrieval options.
It's a very very serious downside for me that there are now two MySQL's (three if you count Amazon's Aurora), just like there are multiple Linuxes and two Pythons.
Isn't the number of pythons four? One for C, one for JVM, one for CLR and one in pure Rpython for the pure JIT code. Double them for python 2 and three. That makes it 8.
Having worked with MySQL for years these are all legitimate issues but, as other users have said, they can be managed via upgrades and settings.
Personally, I'm less interested in developer-oriented issues (which are well documented) and much more interested in how people feel they compare in terms of performance and scaling.
Until recently (~5 years I guess, possibly longer now) MySQL beat PostgreSQL in raw read performance and scalability - though you'd have to scale MySQL sooner. PostgreSQL has been better than MySQL for high-write workloads (thanks to MVCC, if you tune autovacuum properly) and for more complex queries as the query planner understands the storage layer.
Modern PostgreSQL has a much better story around horizontal scaling thanks to streaming replication and a lot of work from the Citus Data team. Query performance is greatly improved as well.
There will be any number of reasons to favor PostgreSQL over the DolphinDB and vice versa.
I have owned various on linux, aix, windows, sco-unix, vax from pick, rms, isams, 4gls dbs, ingres, informix, sybase, mssql, db2, oracle, solid, postgres, mysql to mongo, influx, and redis. I hate them all. I found mysql very slow, much slower than postgresql on equivalent datasets/queries. I had done evaluations before choosing an open-source db for a particular project.
And that really is the crux of the thing - comparing benchmarks is usually meaningless, some don't scale as well, some suit a different kind of application, some need to be distributed, some not, it really is on a case by case basis, what is good in one case is not always the case.
Perhaps stating the blindingly obvious for those getting very het up about evangelism...
As time goes on this is become a less and less controversial opinion. There are still some specific use cases which favour competing RDBMS, but the majority of people who choose competitors at the moment is for reasons tangential to functionality and performance.
SQL is SQL is SQL. I have no problems jumping between different flavours of SQL, however what defines my use of them in my own projects is the toolsets I have for managing and maintaining databases.
Over the years, I have built up a collection of tools, drivers and utilities that just makes working with MySQL an absolute breeze across Windows and OS X. There are times that I want to use ODBC to dump a MySQL table or view into Excel/Access for a client, or copy data from a production system to a test system, or set up replication or do some performance reporting, and I like that I have tools set up which can do these things for me at literally the push of a button.
Sure I still use the CLI for MySQL a lot of the time, but nowadays, 75% of my time is spent in GUI tools of one sort or another.
If someone can give me an equivalent suite of these sorts of tools for Postgres that can let me be productive in short order, then I don't much care if the SELECT statement of one system is several milliseconds faster than the other. I don't deal with such huge volumes or mission criticality. I just want ease of management/maintenance.
Also I think it had it's time, great tool in the early days of web dev but not very professional, sure it was improved in recent years but why put so much energy in it instead of other projects like MariaDB or PostgreSQL before, especially now that it's owned by Oracle? I'm amazed by webdev discussing languages, frameworks and the best stack endlessly and then spawning a MySQL without thinking and looking at alternatives like it was 2004.
Are you sure the webdevs discussing every language and the webdevs spawning MySQL are the same people?
I mean, speaking purely about languages, there are lots of webdevs who just love PHP and will never consider an alternative to it, even if you make a persuasive argument that PHP is unsuited to the use case they're writing for. It's the same sort of "like it was 2004" mentality in a slightly different context. I actually wouldn't be surprised if that's what it is, because those are the M and P in the LAMP stack that everyone seems to have started learning at around that time.
I don't mean to pick on PHP here; it's just the one I see the most that has this property.
The company that wrote it is a Postgres consulting firm so take it with a grain of salt.
Kind of like an AngularJS consulting firm that took thousands of hours to become an expert in Angular writing an article about how horrible they determined ReactJS is after 3 hours with it.
Edit: With that said, I've been a mySQL user for years (decades?) and it does have some obvious short comings that PostgreSQL does not. I often times consider switching but the thing is that in 90% of my projects the database engine is not relevant.
TL;DR a couple of examples where pgsql doesn't silently coerse data values. How to choose one would be a worthwhile article. If someone has a reference to such, a link would be appreciated. The comments in the thread are great starters.
[+] [-] kaamos|8 years ago|reply
Speaking of comparing MySQL and PostgreSQL functionality, I've been spending some time recently on this very topic. Both are great databases with interesting and sometimes unique features. Here are some of the features PostgreSQL is missing as compared to MySQL:
- synchronous multi-master cluster (Galera, Group Replication)
- distributed in-memory grid with automatic sharding (NDB)
- semi-synchronous replication (will be available in PostgreSQL 10)
- built-in logical replication (will be available in PostgreSQL 10)
- built-in event scheduler
- clustered indexes
- declarative partitioning (limited functionality will be available in PostgreSQL 10)
- optimizer hints
- optimizer tracing
- efficient MVCC implementation that is unaffected by XID wraparound problems and VACUUM issues (see also Uber's report on moving from PostgreSQL to MySQL)
- page-level compression
- page-level encryption
- page-level incremental backups
- user variables
- NoSQL client APIs (HandlerSocket, memcached protocol, X protocol)
- virtual columns
- ability to choose data page size on database creation
- ability to specify column order when adding a new column with ALTER TABLE
- write-optimized storage engines similar to MyRocks and TokuDB
All of that may seem small from a developer's standpoint. Those things, however, are huge for people who design and operate the busiest websites on the internet. Which is probably why MySQL still shines in that field.
[+] [-] fusiongyro|8 years ago|reply
I think Postgres will be a better product when it incorporates similar functionality, but the implementations in MySQL and Oracle lie somewhere on the border between false advertising and reckless endangerment. I appreciate that Postgres not having it as two-lines of configuration sends a message that you are making a commitment. Nearly everything else in Postgres is set-it-and-forget-it. You really want to have a DBA if you're going to try to make replication work. When you read the docs on having a hot standby and how much of a commitment that is and sense yourself getting tired, you're starting to appreciate what you might be getting yourself into with single-master replication, let alone multi-master.
[+] [-] fulafel|8 years ago|reply
I don't think the comments read like that. Someone pointed out that some MySQL variants have changed the default in a recent version and the author criticised the defaults, so the implication is that he wasn't using a bleeding-edge MySQL installation and got the previous defaults.
[+] [-] gmac|8 years ago|reply
No. Speaking as an outsider, the Postgres community is about the nicest (and smartest) there is.
[+] [-] glogla|8 years ago|reply
Which doesn't work, see [1]. What other features of those you listed the authors claim that work, and just don't when you look deeper?
Lot of the big companies are using MySQL as a NoSQL database, and that's not a bad way to use MySQL, but it's a pretty bad relational database, see [2].
[1]: https://aphyr.com/posts/327-call-me-maybe-mariadb-galera-clu...
[2]: https://grimoire.ca/mysql/choose-something-else
[+] [-] porker|8 years ago|reply
> - page-level encryption
This got me excited, but for anyone else looking: to keep the key securely (not in a file on the DB server, where an attacker can get it + the DB files) you need to but MySQL Enterprise Edition. Quoting from https://dev.mysql.com/doc/refman/5.7/en/innodb-tablespace-en...:
> The InnoDB tablespace encryption feature in non-enterprise editions of MySQL uses the keyring_file plugin for encryption key management, which is not intended as a regulatory compliance solution. Security standards such as PCI, FIPS, and others require use of key management systems to secure, manage, and protect encryption keys in key vaults or hardware security modules (HSMs).
[+] [-] marcosdumay|8 years ago|reply
Yes, MySQL is all featureful¹. The only thing missing there is guarantees that your data will stay good.
1 - Some of those are "no, we won't ever implement it" features that will do nothing but eat your data by design. Why would you ever want them in a persistence layer? Cache on memory somewhere better.
[+] [-] antoaravinth|8 years ago|reply
Create a table like the following:
create table user (name varchar(4));
MySql:
insert into user (name) values ('antoaravinth');
The above statement works even though I have given the size of my varchar as 4! And retrieving gives me `anto`!!
Postgres:
insert into user (name) values ('antoaravinth');
Stops me there with the relevant exception! That shows how Postgresql is doing small things right.
After seeing this, I never used MySql!
[+] [-] grogers|8 years ago|reply
[+] [-] feld|8 years ago|reply
> - optimizer tracing
Hints are bad. They always have been. If you need hints your query planner is broken.
https://wiki.postgresql.org/wiki/OptimizerHintsDiscussion
Even Oracle Tom says DO NOT USE HINTS IN PRODUCTION! Report the bug to Oracle and let them fix it properly.
[+] [-] teddyh|8 years ago|reply
[+] [-] sigi45|8 years ago|reply
Not sure of your other points, i have no need for them.
What i really don't like on MySQL (and i don't care for a lot of other stuff): MySQL 5.6 (yeah don't forget your version numbers) really sucks for queries with or.
It sucks to write 2 selects with an union which is 100x faster than the same query with one select and ONE or.
[+] [-] Nican|8 years ago|reply
[1] https://cloud.google.com/spanner/docs/schema-and-data-model#...
[+] [-] jeffdavis|8 years ago|reply
A lot of people simply don't care about database semantics though. Possible reasons:
* They are more interested in a particular application (e.g. wordpress), and use whatever default database it seems to prefer.
* They are more interested in a particular framework/library (e.g. django), and use whatever database it seems to prefer.
* They don't see any reason a database should have interesting semantics, because it's just a place to stash data until you need it again.
* They really care about programming languages, but see SQL as a second-class citizen that looks archaic and is really just an obstacle to work around using cool language features.
I believe database semantics do matter. It's hard to make a single argument that will convince everyone, but here are a couple things to consider:
* SQL catches errors that may be impractical to catch even with haskell. For instance: you could have had a bug in the application three versions ago that lead to an inconsistent database state (e.g. a duplicated item ID), and you are just finding the bug now. SQL to the rescue: if the unique constraint exists, then you are fine, and the error would have been raised three versions ago before it ever got in the database.
* Few languages have anything that comes close to ROLLBACK. Erlang kind of does, in the sense that it's a mostly-functional language and a process crash mostly resets you to a good state. But the guarantees of ROLLBACK are much stronger and clearer. I believe this is actually why erlang never really took off widely -- a PHP script hitting the database is a better version of the same concept: the PHP code can crash, and that will cause a lost connection and a ROLLBACK in the database, getting you back to a known-good state and the other requests just continue working (security and other PHP jokes aside).
Rambling a bit, but I believe postgres really is the leader when it comes to database semantics, and I believe that is one of its most important contributions.
[+] [-] defined|8 years ago|reply
Comparing Erlang to PHP + transactional DB is regrettable.
Firstly, Erlang's "let it crash" philosophy, together with its sophisticated supervisor/worker framework, aims for resilience in the face of failure due to bugs or bad data. A PHP script hitting a database may be a better design for a simple web application, but it is in no way superior to the Erlang/OTP ecosystem for Erlang's primary use case: soft real-time, highly concurrent, resilient and robust systems. It cannot reasonably be compared to a scripting language + DB, nor does it make any sense to.
Secondly, Erlang is also able to work with transactional databases, from its built-in Mnesia DBMS to Postgres and more. A more appropriate comparison would be between Erlang + DB vs PHP + DB, and then I think you will agree that Erlang would generally fare better than PHP in that case.
WhatsApp was built almost entirely in Erlang + Mnesia. I honestly don't think they could have done it in PHP + Postgres.
Finally, claiming that Erlang didn't take off because it lacked the transactional semantics of PHP + DB does not compute, because I never saw any claim that Erlang offers transactional DB semantics (unless it happens to be using a transactional DB).
[+] [-] stephenr|8 years ago|reply
[+] [-] iso-8859-1|8 years ago|reply
There is even a real relational database system in Haskell that actually obeys the laws relational algebra, unlike SQL.
https://github.com/agentm/project-m36/blob/master/docs/on_nu...
[+] [-] Aeolun|8 years ago|reply
The people who just want a relational database that does what they need it to in 99% of the cases use MariaDB.
The purists, or people that specifically need it for some specific feature use PostgreSQL.
[+] [-] cygned|8 years ago|reply
[+] [-] imhoguy|8 years ago|reply
[+] [-] anhtran|8 years ago|reply
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] paulryanrogers|8 years ago|reply
[+] [-] Buttons840|8 years ago|reply
[+] [-] concede_pluto|8 years ago|reply
And not everything on the list has a fix available. Off the top of my head, there are still broken storage engines that can't rollback, not all of them can be disabled, and STRICT_ALL_TABLES won't stop you from writing to them. Some foreign key constraints are supported while others are parsed and then silently ignored.
[+] [-] sambe|8 years ago|reply
[+] [-] sitharus|8 years ago|reply
I know I could put the logic in my application, but I like the certainty that comes with knowing what I put in is what I get out.
[+] [-] chisleu|8 years ago|reply
Of course, not ignoring warnings is SOP with mysql.
[+] [-] stickfigure|8 years ago|reply
PostgreSQL has transactional DDL. MySQL does not.
...and the conversation is finished.
[+] [-] tscs37|8 years ago|reply
I do recommend to read through the PGSQL manual (thick PDF file but you can work through the important parts in a week), it's a joy to read compared to the MySQL one.
[+] [-] taneem|8 years ago|reply
[+] [-] rypskar|8 years ago|reply
[+] [-] KurtMueller|8 years ago|reply
[+] [-] mathnode|8 years ago|reply
This seems purposefully contrived; just another developer who throws their toys out of the pram, because they don't read the documentation and just expect software to work for them.
If anything the author has done nothing more than demonstrate ignorance, malice, or both.
When choosing a database, of any kind, you are choosing where to store precious data! Read the fine manual! MariaDB, MySQL, PostgreSQL, and even the likes of MongoDB offer so many diverse options and storage formats and retrieval options.
[+] [-] d_burfoot|8 years ago|reply
[+] [-] kronos29296|8 years ago|reply
[+] [-] mrobins|8 years ago|reply
Personally, I'm less interested in developer-oriented issues (which are well documented) and much more interested in how people feel they compare in terms of performance and scaling.
[+] [-] sitharus|8 years ago|reply
Modern PostgreSQL has a much better story around horizontal scaling thanks to streaming replication and a lot of work from the Citus Data team. Query performance is greatly improved as well.
[+] [-] nthcolumn|8 years ago|reply
I have owned various on linux, aix, windows, sco-unix, vax from pick, rms, isams, 4gls dbs, ingres, informix, sybase, mssql, db2, oracle, solid, postgres, mysql to mongo, influx, and redis. I hate them all. I found mysql very slow, much slower than postgresql on equivalent datasets/queries. I had done evaluations before choosing an open-source db for a particular project.
And that really is the crux of the thing - comparing benchmarks is usually meaningless, some don't scale as well, some suit a different kind of application, some need to be distributed, some not, it really is on a case by case basis, what is good in one case is not always the case.
Perhaps stating the blindingly obvious for those getting very het up about evangelism...
[+] [-] beefsack|8 years ago|reply
[+] [-] cyberferret|8 years ago|reply
Over the years, I have built up a collection of tools, drivers and utilities that just makes working with MySQL an absolute breeze across Windows and OS X. There are times that I want to use ODBC to dump a MySQL table or view into Excel/Access for a client, or copy data from a production system to a test system, or set up replication or do some performance reporting, and I like that I have tools set up which can do these things for me at literally the push of a button.
Sure I still use the CLI for MySQL a lot of the time, but nowadays, 75% of my time is spent in GUI tools of one sort or another.
If someone can give me an equivalent suite of these sorts of tools for Postgres that can let me be productive in short order, then I don't much care if the SELECT statement of one system is several milliseconds faster than the other. I don't deal with such huge volumes or mission criticality. I just want ease of management/maintenance.
[+] [-] hartror|8 years ago|reply
[+] [-] tarsinge|8 years ago|reply
https://news.ycombinator.com/item?id=15166410 https://news.ycombinator.com/item?id=15160149
Also I think it had it's time, great tool in the early days of web dev but not very professional, sure it was improved in recent years but why put so much energy in it instead of other projects like MariaDB or PostgreSQL before, especially now that it's owned by Oracle? I'm amazed by webdev discussing languages, frameworks and the best stack endlessly and then spawning a MySQL without thinking and looking at alternatives like it was 2004.
[+] [-] thehardsphere|8 years ago|reply
I mean, speaking purely about languages, there are lots of webdevs who just love PHP and will never consider an alternative to it, even if you make a persuasive argument that PHP is unsuited to the use case they're writing for. It's the same sort of "like it was 2004" mentality in a slightly different context. I actually wouldn't be surprised if that's what it is, because those are the M and P in the LAMP stack that everyone seems to have started learning at around that time.
I don't mean to pick on PHP here; it's just the one I see the most that has this property.
[+] [-] teddyh|8 years ago|reply
[+] [-] threeseed|8 years ago|reply
If you are going to blog about how bad a particular technology is it surely makes sense to understand it first.
[+] [-] throwaway2016a|8 years ago|reply
Kind of like an AngularJS consulting firm that took thousands of hours to become an expert in Angular writing an article about how horrible they determined ReactJS is after 3 hours with it.
Edit: With that said, I've been a mySQL user for years (decades?) and it does have some obvious short comings that PostgreSQL does not. I often times consider switching but the thing is that in 90% of my projects the database engine is not relevant.
[+] [-] karmakaze|8 years ago|reply