There are certainly situations where other database solutions will perform better. For example, PostgreSQL is missing features needed to perform well on some of the more difficult queries in the TPC-H test suite (see the Chapter 8, Database Benchmarking for more details). It's correspondingly less suitable for running large data warehouse applications than many of the commercial databases. If you need queries like some of the very heavy ones TPC-H includes, you may find that databases such as Oracle, DB2, and SQL Server still have a performance advantage worth paying for. There are also several PostgreSQL-derived databases that include features, making them more appropriate for data warehouses and similar larger systems. Examples include Greenplum, Aster Data, and Netezza.

For some types of web applications, you can only get acceptable performance by cutting corners on the data integrity features in ways that PostgreSQL just won't allow. These applications might be better served by a less strict database such as MySQL or even a really minimal one like SQLite. Unlike the fairly mature data warehouse market, the design of this type of application is still moving around quite a bit. Work on approaches using the key-value-based NoSQL approach, including CouchDB, MongoDB, and Cassandra, are all becoming more popular at the time of writing this. All of them can easily outperform a traditional database, if you have no need to run the sort of advanced queries that key/value stores are slower at handling.

But for many "normal" database use cases, in the middle ground between those two extremes, PostgreSQL performance in 8.3 reached a point where it's more likely you'll run into the limitations of your hardware or application design before the database is your limiting factor. Moreover, some of PostgreSQL's traditional strengths, like its ability to handle complicated queries well and its heavy programmability, are all still there.