zlacker

I only have a couple of points regarding this.

First, simply, I don't know anyone that puts their DB connections "on the internet". That live, raw, database "SQL" socket to be poked, prodded, hammered, and cajoled by complete strangers (or their automatronic minions).

Second, is DB latency. Sending "coarse" grained service requests across the planet is one thing compared to the potential volume of random SQL commands that folks do.

Mind, much of that can be mitigated if you build a stored procedure service layer. But classic "2 tier" "client/server" work didn't do that exclusively, just just threw out SQL willy nilly as the need dictated.

As old school as I am, even I tend to shy away from the "monolithic DB". You think your app was a monolith before, wait until it's all baked into Oracle. I've always found the DB to be a "bad citizen" when it comes to things like versioning, source code control, etc.

Even if I were doing a desktop app, I still think I would prefer a middle tier ("application server") managing service endpoints than cram it all into the DB, especially today.

>>whartu+(OP)
Shodan knew at least 600,000 PostgreSQLs listening on the open internet when I last looked. Presumably quite a few are mistakes, of course. But people do it and the sky doesn't fall. Same for SSH or many other types of server. Of course the web ecosystem has 30 years of accumulated work so yes, you'd be missing stuff like Cloudflare, reCAPTCHA etc. Better for more controlled contexts than something like HN.

Latency is easy to screw up whether you do web apps or direct SQL connections. You have to be conscious of what a request costs, and you can easily batch SQL queries. Yes, you have to watch out for frameworks that spam the DB but those are bad news anyway, and of course there are lots of web frameworks that generate inefficient code. Not sure it's so different.

Your app will have to deal with DB versioning whether it's a web app or not. Tools like Flyway help a lot with linking your DB to version control and CI.

Nonetheless, I totally understand where you're coming from. Thanks for the thoughts.

>>mike_h+M4
>* Shodan knew at least 600,000 PostgreSQLs listening on the open internet when I last looked. Presumably quite a few are mistakes, of course.*

A few? I'd say most are accidental and the rest are just bad ideas...

>But people do it and the sky doesn't fall.

Well, the same is true for playing Russian roulette too. Most of the times you're winning!

>>coldte+g7
We don't know either way, but a standard Postgres install doesn't let remote connections do much. You still have to authenticate before anything is allowed. It's not much different to sshd in this regard. A typical web server is far more promiscuous, with a massive surface area exposed to unauthenticated connections. There have been way more disasters from buggy web frameworks/apps that get systematically popped by crawlers, than from people running RDBMS.

>>whartu+(OP)
What specifically are you concerned about? An HTTP connection to NGINX is just a TCP connection anybody can open, a database connection to postgres is the same. Both applications need to be extremely careful with those connections to protect against attacks, but database security is already a huge priority, so they both have invested heavily in that.

One concern I can think of is NGINX might have better DoS protection. What else do you have in mind?