PostgreSQL mininum requirements
There has been a lot of talk through the years of what the minimum set of hardware requirements are for a PostgreSQL database. Generally speaking the requirements for PostgreSQL are very low, you can even get by on 256 Megs of memory. However you rarely hear or read about what would be considered the minimum production hardware requirements for PostgreSQL.

A primary reason for this is that every business has their own requirements and thus one persons minimum requirements are not another persons minimum requirements. Of course since we are in geek world and many geeks are uniquely pedantic and unable to see outside of their own bubble, my requirements may be wrong without any understanding of business requirements as a whole. So what do we do? We voice our opinion anyway. The requirements listed do make some business assumptions. First we are talking about minimum production requirements. Second, scheduled outages do not impact your uptime percentages.

Minimum Production Requirements

  • 64bit CPU
  • 64bit Operating System
  • 2 Gigabytes of memory
  • Dual CPU/Core
  • RAID 1

64bit CPU 32bit on the server is dead. Long live 64bit. The reality is if you run 32bit you have no scalability. Further 32bit CPUs won't even access 4Gig of memory properly. Suck it up. If anyone tells you that you don't need 64bit. Fire them. They are saying, "You will not grow this database. You will not need to scale this database."

64Bit Operating System This is all about scalability. A 32bit operating system can handle 4G of memory per CPU, poorly. You don't get access to the full 4G because you have to load special extensions to access that much memory on 32bit. In short there is zero reason to run 32bit as a general purpose operating system for your database (embedded etc.. is obviously excluded). At this time PostgreSQL is only native 64bit for Linux/UNIX operating systems. However even on Windows it is still a good idea to run 64bit. PostgreSQL will be running in 32bit mode but the operating system as a whole will be more efficient so it is is still a net win.

Memory It is possible to operate PostgreSQL on less than 2G of memory. I have seen plenty of people do so in production, happily with 512 megs of memory. For years at a time. However, memory is cheap, and having more will only help the database perform better. Remember that just because your app doesn't need 2G doesn't mean other things that go on behind the scenes can't make use of it. Processes like autovacuum happen without the operator knowing it and it takes up memory.

Dual Core/CPU PostgreSQL is process based. That means it can do exactly one thing at a time. No more. No less. Further if you have only one CPU you will have to context switch more in order to serve the needs of your users and database. Nowadays CPUs are so fast that most people won't notice. Do you ever want to be in a position to notice? No. You do not. Get a dual core CPU. Even if your application velocity doesn't warrant it, it means you have some scalability. It also means that you will have a more balanced load when routine maintenance tasks are running.

Raid Anything less than RAID 1 (e.g RAID 0 or non raid) is a recipe for disaster. You have zero reliability. RAID 10 would be preferred but these are minimum requirements. The next question of course is, "What kind of hard drives should I use?" . It doesn't matter. People will tell you it matters. It doesn't. It is all about your requirements. Dollar per capacity, SATA is the top dog. However you pay a penalty for using SATA and no it isn't in reliability. (There was a recent USENIX published study that shows the reliability differences between SATA and SAS/SCSI are not even worth mentioning). The penalty is performance. Generally speaking it takes 2 SATA drives to give you the same basic performance as a single SAS drive. When dealing with larger capacity drives (anything above 70G) you can usually purchase 2 SATA drives for less than the price of a single SAS drive. Hardware or Software RAID? This greatly depends on your requirements. On Linux software RAID is very easy to manage and install. Your CPU is faster than the hardware raid controller CPU anyway. You will not be able to HOT SWAP. You will have a scheduled outage, replace the drive and then have to execute some Linux commands to bring the drive back online. If properly configured replacement is a very quick operation resulting in a halt, yank, push, start, execute, done. The Windows platform does support software RAID for RAID 1 (it also supports others but you would never use RAID 5 or 0 with a database). There is a theoretical problem with Software RAID, especially those that have large cache. If you have an operating system crash or an instant loss of power, it is possible that you may corrupt your database. I have never been able to produce this however. Either way, make sure you have a UPS that performs proper shut down procedures in case of a power outage. If hardware RAID is within the budget I would suggest taking a look. Here are the key ingrediants to good Hardware RAID:

  • Lots of cache on controller
  • Battery backup unit for controller
The Battery backup unit for the controller is not optional. Do not think that it is. It isn't. There are known decent hardware RAID controller providers. They are LSI, ARECA and 3WARE for SATA. For SAS/SCSI, LSI and HP are the known to work very well. Do not be fooled by on board LSI OEM chipsets. They are not the same. If you would like to comment on this blog I suggest starting a thread on pgsql-general.