3 ms·

My view is that a single PostgreSQL box can handle reliably and efficiently enough queries than a comparable MySQL box. This is not to say that one is better th

by neya 14y ago

My view is that a single PostgreSQL box can handle reliably and efficiently enough queries than a comparable MySQL box. This is not to say that one is better than the other, it depends on a lot of things, but I am actually addressing only the pain points. PostgreSQL's enterprise brother, powered by enterprisedb has a cloud solution that takes care of scaling while you can focus on your code.[1] I had this in mind when I was writing that sentence. Also, here's some more inks to research about: http://stackoverflow.com/search?tab=votes&q=postgresql%20%20vs%20mysql http://stackoverflow.com/search?tab=votes&q=postgresql%2... Again, I don't say using PostgreSQL is a magical solution for your next app. Just that in my opinion it is better than MySQL. [1]http://www.enterprisedb.com/products-services-training/products-overview/postgres-plus-cloud-database http://www.enterprisedb.com/products-services-training/produ...

vidarh 14y ago
I've used Postgres for the last 5 years, and mostly MySQL before that. But while I love a lot of features in Postgres, my big caveat with it is that Postgres seems to have an attitude of "if we can't do it perfectly, we won't do it yet", and so we only got "proper" replication recently (or had to deal with third party hacks on top of triggers or the like) and still can't do multi-master replication without third party hacks. Meanwhile, MySQL have had multi-master replication "forever" because they took the easy way out of "simply" logging statements, and streaming those to slaves, and add a mechanism for adding offsets and step sizes to sequences. It's a bit of a hack, and vulnerable (if you do clashing updates, replication will fail), but in real life usage it gave MySQL a massive advantage for some types of scenarios for a long time (e.g. back in 2006 I ran a cluster of 16 MySQL servers spread over two sites; configuration was trivial while doing the same with Postgres at the time was a massive PITA). It's a philosophical difference that means that while I'd be more comfortable about trusting our payroll data to Postgres, for a web app where major scalability is a concern, I'd be prepared to consider MySQL in situations where I'd consider Postgres a no-go because of the hassle. Postgres feels like it has a more theoretically sound foundation, and is catching up feature-wise, though. A few more iterations on the replication support, and extensions like https://code.google.com/p/plv8js/wiki/PLV8 https://code.google.com/p/plv8js/wiki/PLV8 (run Javascript in Postgres via V8, which also instantly gives nice JSON support to rival many of the no-sql solutions) and it's eating it's way into both the no-sql space and the space held by MySQL.
falcolas 14y ago
"a single PostgreSQL box can handle reliably and efficiently enough queries than a comparable MySQL box" Sorry, but citation needed. Most of the (relevant) stack overflow results are pointing to articles citing 4.1 and earlier MySQL versions, or pure FUD opinion pieces. MySQL and PostgreSQL are within the same order of magnitude (depending on workload and how much time you're willing to spend optimizing queries) for a single server, so to say that PostgreSQL is better requires some backing up with actual numbers or techniques.

by neya 14y ago

vidarh 14y ago

I've used Postgres for the last 5 years, and mostly MySQL before that. But while I love a lot of features in Postgres, my big caveat with it is that Postgres seems to have an attitude of "if we can't do it perfectly, we won't do it yet", and so we only got "proper" replication recently (or had to deal with third party hacks on top of triggers or the like) and still can't do multi-master replication without third party hacks. Meanwhile, MySQL have had multi-master replication "forever" because they took the easy way out of "simply" logging statements, and streaming those to slaves, and add a mechanism for adding offsets and step sizes to sequences. It's a bit of a hack, and vulnerable (if you do clashing updates, replication will fail), but in real life usage it gave MySQL a massive advantage for some types of scenarios for a long time (e.g. back in 2006 I ran a cluster of 16 MySQL servers spread over two sites; configuration was trivial while doing the same with Postgres at the time was a massive PITA). It's a philosophical difference that means that while I'd be more comfortable about trusting our payroll data to Postgres, for a web app where major scalability is a concern, I'd be prepared to consider MySQL in situations where I'd consider Postgres a no-go because of the hassle. Postgres feels like it has a more theoretically sound foundation, and is catching up feature-wise, though. A few more iterations on the replication support, and extensions like https://code.google.com/p/plv8js/wiki/PLV8 https://code.google.com/p/plv8js/wiki/PLV8 (run Javascript in Postgres via V8, which also instantly gives nice JSON support to rival many of the no-sql solutions) and it's eating it's way into both the no-sql space and the space held by MySQL.

falcolas 14y ago

"a single PostgreSQL box can handle reliably and efficiently enough queries than a comparable MySQL box" Sorry, but citation needed. Most of the (relevant) stack overflow results are pointing to articles citing 4.1 and earlier MySQL versions, or pure FUD opinion pieces. MySQL and PostgreSQL are within the same order of magnitude (depending on workload and how much time you're willing to spend optimizing queries) for a single server, so to say that PostgreSQL is better requires some backing up with actual numbers or techniques.