But don't overdo it beyond what is needed. Yes, the DB server needs a firewall, needs good access controls, needs backups.
But you probably don't need 5 slave DBs in 3 different geographical zones so that you "try" to achieve 5 9's of reliability for your service that has 100 sales per day.
Does it?
My recently-built DB machine has 4 listening network sockets that are bound to non-local interfaces: tcp/22:sshd (so I get in), tcp/5432:postgresql (because it's DB server, huh), udp/123:ntpd (so clocks are in sync) and tcp/443:nginx (serves some static pages with performance data).
I don't see any place where firewalling's needed.
What if done program you don't realization is installed opens a port somewhere?
So not strictly necessary for correct operation, but then again security is all about being defensive....
I don't see where I made any mention of your specific setup in my statement.
Famous last words. You won't need a firewall until you need one, but then it's too late.
Many DB developers consider it good practice to be paranoid about who has access to the DB port, even if they can't authenticate:
http://www.postgresql.org/support/security/faq/2013-04-04/
"Any system that allows unrestricted access to the PostgreSQL network port, such as users running PostgreSQL on a public cloud, is especially vulnerable. Users whose servers are only accessible on protected internal networks, or who have effective firewalling or other network access restrictions, are less vulnerable.
"This is a good general rule for database security: do not allow port access to the database server from untrusted networks unless it is absolutely necessary. This is as true, or more true, of other database systems as it is of PostgreSQL."