25 ms·
It's amazing how the newcomers to tech seem to ignore 'proven' databases like PostgreSQL so easily that have actually stood the test of time and actually have t
by neya 14y ago
It's amazing how the newcomers to tech seem to ignore 'proven' databases like PostgreSQL so easily that have actually stood the test of time and actually have the real capacity to scale enormously on demand (which when done right). What is more disappointing is how the newcomers seem to trade in for beta-quality NoSQL databases that promise them of better reliability and scalability out of the box, which is simply not true[1]. For instance, databases like MongoDB promise the developer to not worry about scalability and focus just on their code, while it does some things under the hood in a terrible way [2].
PostgreSQL is one of the few databases that supports SQL and can actually be less painful to scale than MySQL. Also, the recent versions have enormous performance boost that can silence the SQL critics, IMO.
If you are interested in testing out PostgreSQL for your project, you might want to develop on the WAPP stack and give it a shot:
http://bitnami.com/stack/wapp http://bitnami.com/stack/wapp
Disclaimer:
I was a mongoDB developer too and I loved it so much. I loved the fact that I could skip running db migrations on my rails app and I can focus on just coding, instead of worrying about scaling. But, it was a terrible trade off. First of all, you can't use NoSQL for everything. It was a very painful lesson that I learned the wrong way. 99% of the time, you want to use SQL, because most use cases can be executed perfectly with SQL db's. Next, some db's have a terrible architecture and design decisions under the hood, mainly to improve their benchmarks (seriously!). For example, turning off write-safe by default... :cough: :cough:
Last but not the least, SQL for the wrong use case complicates things and ends up adding redundancy into the database (like storing User details inside multiple collections, un-avoidable, especially when you are against embedding documents). The worst trade-off using a NoSQL database is the analytics part - "Hey db, show me the list of users who are from the United States and who have subscribed to Plan X and who are the highest paying customers and who love chocolate pie"
SQL - "Here you go." NoSQL - "Sorry sir, not possible. Possible, but possibly a nightmare."
If you want to build a 'scalable' app for your next big thing and don't want the scaling hassles of MySQL, which actually scales extremely well already[3], you can use PostgreSQL.
Cheers
[1]Scaling is hard. Don't let anyone else tell you otherwise!
[2] http://blog.engineering.kiip.me/post/20988881092/a-year-with-mongodb http://blog.engineering.kiip.me/post/20988881092/a-year-with...
[3] http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-or-CouchDB http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use...
- falcolas 14y ago"... can actually be less painful to scale than MySQL." Can you expand on this? All that I'm aware of, in the scaling department, is their basic replication introduced recently.
- neya 14y agoMy 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 agoI'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.