I've seen on DBA and other sites that exposing a database to the Internet is a particularly bad idea, but I noticed that PostgreSQL has SSL-certificate-only authentication. Does this make it any safer to expose a database to the internet (cert-only auth from non-localhost connections) or would it still be better to establish a VPN, or tunnel through SSH etc?

If the latter is safer, what exactly makes it safer? I feel like I am overlooking something glaringly obvious in this regard.

I've set up a handful of databases before but never actually needed to set one up that requires some sort of remote administration (“remote” in this case meaning over the Internet or WAN rather than a LAN).

2 Answers 2


It's not really about it being a bad idea in general, more that there are very few instances where you really need to expose your database to a public interface.

Much of security is about reducing the number of attack surfaces you expose. If your application does not absolutely have to expose your database to the public then you can hide it away behind a firewall and have another level of protection from any potential exploit that might appear in the future.

I would not consider "remote administration" a good enough reason to expose postgres. As you say; you already need SSH access to your box so you could easily keep postgres behind a firewall and gain access via that without any problems.

RE: SSL connections. This would be a must unless you were happy with third-parties just reading your data while you send it over the wire. The considerations here are the same as any traffic over the public internet.

  • This makes sense. If for example I had a front-end already developed to make direct connections to the database, would it still be better to tunnel these through a VPN or SSH connection?
    – dreamlax
    Commented Jun 10, 2013 at 3:42
  • 2
    @dreamlax No, so long as you keep PostgreSQL patched up to date (like any other service) it's quite safe to just use SSL directly, especially if you also require a valid client certificate, restrict the user to minimum access privileges, etc. Staying patched is important: security holes in Pg are rare, but there was a nasty one recently: postgresql.org/support/security/faq/2013-04-04 Commented Jun 10, 2013 at 6:55
  • I'm marking this one as the answer because of your explanation about minimising "attack surfaces", but I'm still failing to understand the benefits of shifting security elsewhere. I'm inclined to follow @CraigRinger's advice.
    – dreamlax
    Commented Jun 11, 2013 at 2:49
  • Just as a note, Heroku DB's are exposed over the public network.
    – Ron E
    Commented Dec 6, 2013 at 4:37

The only scenario I can imagine where it could be necessary to expose your database to internet is for replication or clustering purposes. If this is the case, you should limit the access just to the additional hosts via firewall.

For any other uses, I would suggest you to create web services acting as gateways to access the database. These services will provide just the functionalities you need and you will be responsible of their security and integrity.

In fact, any web front-end connecting to a database makes this sort of things, using the scripts on the web server as RESTful web services.

  • 3
    How is the web service inherently more secure though? Why is shifting security to a web server more secure than leaving it with the database, especially if the database only accepts connections from those with valid certs? The problem is, if I have to expose the database via a web service this will require changing a lot of code in the existing front-end (which is not web-based). If it is the only way, then I'll just have to do it, but I need to know what the risks are of having a database exposed if it is configured only to accept SSL-certified connections.
    – dreamlax
    Commented Jun 10, 2013 at 6:24
  • 2
    IMO doing this just trades one security risk for another, it doesn't really gain you anything over a properly locked down Pg talking over SSL to a remote user whose account has been configured to have the minimum access rights required to do what they need. Commented Jun 10, 2013 at 6:54
  • You can make your web services secure, and serve only to clients with valid certificates. The advantage is the web service not offering the whole range of operations the database offers. Your web service should only offer the necessary actions required by the client. Any other operation should not be possible through the web service.
    – jap1968
    Commented Jun 10, 2013 at 8:03
  • That still doesn't sound like the web service offers much advantage over having a database user who is only allowed to call a small set of functions (i.e. the same "actions" that the web service offers). Plus, any changes to the database require changes to the web service also, as well as the front-end.
    – dreamlax
    Commented Jun 10, 2013 at 9:47
  • May be the key question is the type of front-end. I tend to assume a web based front-end: it can not communicate as a native database client, i.e, it needs some type of auxiliary web service to access the database.
    – jap1968
    Commented Jun 10, 2013 at 11:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.