Personally the biggest I've worked on was only a little over 3TB, and we only dealt with a few thousand concurrent users hitting it. We had no outages over the course of years attributable to the database. I know there are quite a few larger ones out there, but many of them consider the use of PostgreSQL to be a secret they don't want their competitors to catch on to. Some of the larger users who have already been mentioned are Skype, Instagram, and MyYearbook.Com. Of course some of the main DNS providers use PostgreSQL, which I imagine is reasonable high volume.
You might be interested in Postgres-XC and the logical replication work with is going on currently.
Many of the items on the PostgreSQL "gotcha" list are annotated to say that they only affect older versions; in one case they mention it affects versions 7.4 and earlier. Versions 7.4, 8.0, 8.1, and 8.2 have all hit end-of-life after five or more years of support. Version 8.3 hits end of support in about three months. That would be a very short list if issues from ancient out-of-support versions were culled from it.
Since the release of PostgeSQL version 9.1, PostgreSQL has an optimistic technique for implementing SERIALIZABLE transactions which doesn't require traditional read locks: Serializable Snapshot Isolation. (Full disclosure: this was developed by myself and Dan Ports of M.I.T.) For some performance graphs using several standard benchmarks, see Proceedings of the VLDB Endowment, Volume 5:
This lets you set a default transaction isolation level and just do your work without worrying much about interactions with other transactions, as long as you are set up to retry your transaction from the start on a serailization failure. There is no need for SELECT FOR UPDATE, and since there is a guarantee that any group of serializable transactions will behave the same as some serial (one-at-a-time) execution of those transactions, you can be sure that if the transaction does what you want when run by itself, it will do what you want when run in any mix of serializable transactions -- without the blocking described for SQL Server.
So you can have your transactional consistency without the blocking.
Slashdot Mirror
Personally the biggest I've worked on was only a little over 3TB, and we only dealt with a few thousand concurrent users hitting it. We had no outages over the course of years attributable to the database. I know there are quite a few larger ones out there, but many of them consider the use of PostgreSQL to be a secret they don't want their competitors to catch on to. Some of the larger users who have already been mentioned are Skype, Instagram, and MyYearbook.Com. Of course some of the main DNS providers use PostgreSQL, which I imagine is reasonable high volume.
You might be interested in Postgres-XC and the logical replication work with is going on currently.
Many of the items on the PostgreSQL "gotcha" list are annotated to say that they only affect older versions; in one case they mention it affects versions 7.4 and earlier. Versions 7.4, 8.0, 8.1, and 8.2 have all hit end-of-life after five or more years of support. Version 8.3 hits end of support in about three months. That would be a very short list if issues from ancient out-of-support versions were culled from it.
PostgreSQL: Versioning policy
Since the release of PostgeSQL version 9.1, PostgreSQL has an optimistic technique for implementing SERIALIZABLE transactions which doesn't require traditional read locks: Serializable Snapshot Isolation. (Full disclosure: this was developed by myself and Dan Ports of M.I.T.) For some performance graphs using several standard benchmarks, see Proceedings of the VLDB Endowment, Volume 5:
http://vldb.org/pvldb/vol5/p1850_danrkports_vldb2012.pdf
This lets you set a default transaction isolation level and just do your work without worrying much about interactions with other transactions, as long as you are set up to retry your transaction from the start on a serailization failure. There is no need for SELECT FOR UPDATE, and since there is a guarantee that any group of serializable transactions will behave the same as some serial (one-at-a-time) execution of those transactions, you can be sure that if the transaction does what you want when run by itself, it will do what you want when run in any mix of serializable transactions -- without the blocking described for SQL Server.
So you can have your transactional consistency without the blocking.