I would emphasise the point made about Postgres read performance. If all you are doing is reading single rows from a single table using an index, then yes Postgres is overkill and other solutions may perform better. However, the overhead that Postgres has is due to a remarkably effective query planner, which can be a godsend if you have a complex multi-table join. A few years ago I was working on a project with a large Postgres database that regularly did queries joining 20 tables together, which Postgres was quite happy to accommodate.<p>Also, that overhead can be suffered only once for many similar queries if you make use of prepared statements, which can bring the performance of simple read queries up.<p>Also, bulk writes can be sped up through the COPY IN BINARY interface - we were getting bulk load speeds basically limited by the write speed of our RAID array.<p>In short, I have been very impressed indeed with Postgres. They do it right.
I'm not sure why this is being upvoted. It's very light on technical content (how can you mention sqlite and not say that its type system is advisory only is beyond me), and provides no added value compared to what you can get out of a quick google search if you wanted to compare these three widely used RDBMS.<p>I'll note that I usually disagree with these "why is this on HN" posts, but technical posts should have a higher bar than this.
One of the biggest benefits of Postgres is WAL-E (<a href="https://github.com/wal-e/wal-e" rel="nofollow">https://github.com/wal-e/wal-e</a>), which allows you to perform streaming backups (based on Postgres' WAL) to <location> (i.e. S3, an file server, etc) and also perform base-backups at regular intervals (so you can replay your WAL backups on top of it).
"Again, depending on the choice of the database-engine, MySQL can lack certain features, such as the full-text search."<p>Both of the two biggest engines (MyISAM, InnoDB) support full-text search. It was added to InnoDB in MySQL 5.6/Maria 10.
MySQL Advantage: "MySQL can be installed very easily"<p>I've always heard MySQL's popularity had a lot to do with how easy it was to install, but now a days, I really can't see install ease being a factor. The date for the document says February 21, 2014, so they should know about EnterpriseDB and their installer or maybe my idea of easy is different.<p>In my opinion EnterpriseDB did a really good job with their Postgres installer. They certainly designed it to be easy to integrate with other products, which makes sense, since more Postgres installs means more potential customers.<p>I was actually taken back by how easy it was to integrate with my products Linux installer. And what makes the installer really nice is, it puts everything in a single directory, which makes all the difference for my product. My product has a Postgres 9 requirement, and I was really worried about losing potential customers who were running Postgres 8 and could not upgrade. But since the install is pretty much self contained, you can happily run Postgres 8 and 9 on the same machine.<p>If you know Perl and are curious, download my product (<a href="http://gitsense.com/download.html" rel="nofollow">http://gitsense.com/download.html</a>) and take a look at the install.pl file. My only complaint with the db installer is, it doesn't provide a way for you to track the install progress. To work around this, I just fork a process which does the db install and I'll print a dot to STDOUT which lets the user know the install is jugging away.
If you're making a web app, IMO you shouldn't use SQLite at all - not even for testing. In a live scenario SQLite has problems with multiple users. And in a test scenario SQLite is too forgiving when it comes to types - which means that once you switch to your live database, e.g. PostgreSQL, errors will occur that you hadn't foreseen because PostgreSQL isn't as forgiving as SQLite type-wise.<p>In short, use PostgreSQL both for testing and live. I recommend Postgres.app for Mac users: <a href="http://postgresapp.com/" rel="nofollow">http://postgresapp.com/</a>
It appears that Postgres is currently more popular among developers than MySQL <a href="http://www.databasefriends.co/2014/03/favorite-relational-database.html" rel="nofollow">http://www.databasefriends.co/2014/03/favorite-relational-da...</a>
Not quite the in-depth article I expected sadly. Very disappointed.<p>As someone who has used all three extensively, I would say steer clear of SQLite for large-scale applications or a web app in production. I tend to use SQLite for prototyping because it means you don't have to worry about setting up a database, I wouldn't use it for much more than that.<p>I used to use MySQL quite a bit, and since version 5.5 MySQL has actually been really good in terms of performance and feature-set. Both MySQL and PostgreSQL have their advantages, and as long as you know when to scale and shard your database it's all relative in the end regardless of which of the two you choose, both can be tuned to do the same things.
Regarding Postgres vs MySQL performance in conjunction with programming languages, this is kind of interesting:
<a href="http://www.techempower.com/benchmarks/#section=data-r8&hw=i7&test=db&d=6" rel="nofollow">http://www.techempower.com/benchmarks/#section=data-r8&hw=i7...</a>
why do people keep saying that mysql is easier to install and configure postgres? maybe you can find more results when googling for "mysql install" or something, but it's just a bit different, not harder.<p>(...now, I don't even understand why mysql was even created in the first place when even back then there were other open source projects already closer to achieving performance on par with the commercial rdbmss...)<p>EDIT - correction: sorry, swapped two words by mistake and ended up saing the opposite thing
Can the authors somehow back the statement of MySQL's popularity vs. PostgreSQL? If anything, the latter seems more popular, judging from the frequency of its appearances on HN.
For a quite in-depth comparison of various RDBMS, check out <a href="http://troels.arvin.dk/db/rdbms/" rel="nofollow">http://troels.arvin.dk/db/rdbms/</a>
This is just someone who doesn't appear to have much experience with any of the three, repeating "common knowledge" opinions that are largely misguided and/or outdated. If you want to say X is faster or Y has more "security options" (what?) then link to something to demonstrate that.
I love how easy it is to get started with MySQL and historically it's had a great user manual for beginners.<p>For years, though, I've felt that the small problems where SQLite is useful now cover all the former MySQL ground. Once you exceed the power of SQLite, the features and performance and standards compliance and reliability and flexibility and correctness constraints and transaction execution and ongoing feature development of Postgres overwhelm the use case for MySQL.