By "a long period of stagnation" I assume you are referring to public exposure -- because it's not true that Postgres itself has stagnated. Postgres has been d

By "a long period of stagnation" I assume you are referring to public exposure -- because it's not true that Postgres itself has stagnated. Postgres has been developed steadily the last decade, and has been a serious competitor to major RDBMSes since version 8.1 (which added two-phase commit, table partitioning, index bitmap scan and shared row locking, among other things.) I say public exposure because Postgres has clearly been popular among many developers for a long time It's ben beneath the radar for a lot of people, partly due to pervasive myths ("Postgres is slow"), partly due to the fact that, well, a product doesn't sell itself. I think the reason Postgres has shown up on HN a lot is simply that people are finally discovering it and recognizing its technical brilliance, careful engineering and high performance, and it's snowballing. I myself have used Postgres for web apps since 2003 myself, and I have evangelized among colleagues and acquaintances to the best of my abilities, so I am very happy about this progress. I don't see why it should surprise you. While I'm sure MySQL 5.0 and its various forks have gotten better over the years, it's hard to argue that Postgres is not technically superior in pretty much every way. Even if you care solely about performance, which used to be MySQL's main selling point, Postgres has overtaken MySQL a long time ago. > an even more expensive per-connection model than mysql This is not a practical issue for most people, in my experience. At least nobody is really complaining about it. Rails apps happily pool connections, for example. If you can't pool connections in the app, there are several excellent, mature connection-pooling proxies around (including a very cool one, pgPool-II, which can also load-balance and replicate at the same time). > and extremely painful replication Is it possible that you have not been following the developments? If you don't need per-table/per-database replication, then streaming replication is actually incredibly painless. It is by all accounts awesome. And it scales very well. If you do need fine-grained replication, there are several mature third-party projects that are fairly painless to operate, including Bucardo and Londiste. (I would not count Slony as "painless", although it's probably the most comprehensive solution right now. Avoid it unless you are a bank.) There is also a multimaster-replicating fork (PostgreSQL-XC) that is apparently working very well, and implements true distributed ACID replication, as opposed to the kind of "de facto multimaster replication" you set up in MySQL, where you have to make sure primary keys don't overlap between hosts.