We (databaselabs.io) are the first Postgres as a Service on DigitalOcean. We fight this sales battle on a daily basis.
The problem is that younger devs/owners are much less likely to have ever experienced any significant outage, so it's a non-issue for them. They can't see why they should pay good money to prevent it.
We've had much better results with slightly older and more experienced people, who realize that our service is an absolute bargain compared to the cost and risk of attempting to run continuous backups, etc. themselves.
i am curious, you are commenting on a post about secure postgres but after signing up for your service i see that the database i created is publicly available, on the standard port 5432, with the default postgres username. the only thing stopping me is a password, no certificate required. i am not a postgres expert but how is this not extremely insecure?
"Extremely" insecure is a bit of an exaggeration. It's not as though the password is "password" on all the databases.
We do support certificate-based logins and firewalls with IP whitelists. They're just not on by default. Frankly, the reason is because almost all customers don't care about having a very high level of security if that implies doing more work (setting up certificates, whitelisting IPs.) Moreover, they actively prefer to have "simpler and less secure" over "more complex and more secure."
We've done experiments with certificates and firewall IP whitelists and so on. Almost all customers and potential customers reject these things. They say they want a simple password that just works from anywhere.
We had to choose between being slightly less secure and having customers, versus being highly secure and having no customers. Since the business can't survive without any customers, that choice was easy.
That said, if you do want any of those things turned on for your database, just write support@databaselabs.io.
Out of curiosity, can one change these settings for their own databases automatically via some "control panel" or such, or does it require intervention from your staff?
Fortunately, I think there have been fewer "unauthenticated remote access" vulnerabilities with PostgreSQL than MySQL so this (being accessible from 0/0) probably isn't a huge deal. That said, I'd look for ways to restrict who can actually connect to 5432/TCP that won't negatively affect the majority of your customers (e.g., if your databases are running on DigitalOcean, can you restrict connections to that particular DO datacenter by default and provide an option to loosen those restrictions in increments -- "this datacenter", "all DO datacenters", "the world", etc.?).
These settings are currently manually operated by staff, via support@databaselabs.io.
That will get added to the control panel eventually, but right now as approximately zero percent of customers want those things, it's not a good use of our limited engineering time to even automate that, versus other things that engineers could be doing with their time.
While it would be nice in theory to restrict them by default, in practice there's just no restriction that's close enough to universally applicable to be workable (i.e. one that won't disrupt a large number of users' use of the database if it's applied everywhere.)
And you are correct, there are essentially zero unauthenticated remote access vulnerabilities that come out in Postgres. Combine that with:
* All connections require SSL
* The password is a long string of randomly generated characters
* We actively monitor the network for unusual traffic patterns
and it's actually not so bad. Not ideal of course, but very much not "extremely" insecure, as the above post said.
100% uptime is a financial guarantee: if it's up for less than 100% of the time (other than scheduled maintenance), we refund 30x that amount, up to 1 months' fees.
We used to have a more engineery 99.95% uptime guarantee, but customers empirically prefer the financial guarantee over that.
The problem is that younger devs/owners are much less likely to have ever experienced any significant outage, so it's a non-issue for them. They can't see why they should pay good money to prevent it.
We've had much better results with slightly older and more experienced people, who realize that our service is an absolute bargain compared to the cost and risk of attempting to run continuous backups, etc. themselves.