4 ms·

Yeah, it's what Rails is doing. However, if you are doing an app like this, you are building logic around the db mainly. If you are that DB centric, why not hav

Yeah, it's what Rails is doing. However, if you are doing an app like this, you are building logic around the db mainly. If you are that DB centric, why not having Postgres itself serve web requests? There is no consistency with the double approach of having a logic rich app and a logic rich db.

jnbiche 10y ago
You mean "building logic around the db" by using ORMs as opposed to SQL queries?
Scarbutt 10y ago
why not having Postgres itself serve web requests? Primarily, security.
- ruslan_talpa 10y ago
  If by security you mean protection against DOS then yes. If you mean users accessing private data then you are wrong. Postgres (and all the other dbs) have the tools necessary to specify who can access what (one just has to use them).
kuschku 10y ago
> why not having Postgres itself serve web requests? Good question! Why not have all the logic in the database? The answer is, you can actually do that. And it’s popular enough that someone founded a company on that concept, although they didn’t use Postgres, but their own self-built database. You might have heard of it: https://firebase.google.com/ https://firebase.google.com/ (They were acquired later, and are now Google’s top database offering).
- koffiezet 10y ago
  Well, you have https://postgrest.com/ https://postgrest.com/
narrator 10y ago
I've found that it's better to have queries be pretty simple and do any necessary complex aggregations or analysis in the app tier since it's better to let the database's CPU think about doing I/O and cache management rather than business logic. It's also easier to scale out the app tier as you can bring app tier instances up and down easily via AWS vs having to copy a lot of data around to bring up a database replica.
- yawaramin 10y ago
  At the kind of scale you're talking about, I am pretty confident that 90% of people just won't need to do anything on that scale. For most people, business logic in the DB will serve their needs perfectly. And if some day they need to scale up to some level beyond a single DB, I'm also pretty confident that they'll have the resources to spend on a DBA consultant specialising in sharding or replication :-)
yawaramin 10y ago
> ... why not having Postgres itself serve web requests? At least two OSS backend stacks, PostgREST and PostGraphQL, are built on exactly this idea. And there's at least one commercial stack with the same idea: SlashDB.

jnbiche 10y ago

You mean "building logic around the db" by using ORMs as opposed to SQL queries?

Scarbutt 10y ago

why not having Postgres itself serve web requests? Primarily, security.

ruslan_talpa 10y ago
If by security you mean protection against DOS then yes. If you mean users accessing private data then you are wrong. Postgres (and all the other dbs) have the tools necessary to specify who can access what (one just has to use them).

kuschku 10y ago

> why not having Postgres itself serve web requests? Good question! Why not have all the logic in the database? The answer is, you can actually do that. And it’s popular enough that someone founded a company on that concept, although they didn’t use Postgres, but their own self-built database. You might have heard of it: https://firebase.google.com/ https://firebase.google.com/ (They were acquired later, and are now Google’s top database offering).

koffiezet 10y ago
Well, you have https://postgrest.com/ https://postgrest.com/

narrator 10y ago

I've found that it's better to have queries be pretty simple and do any necessary complex aggregations or analysis in the app tier since it's better to let the database's CPU think about doing I/O and cache management rather than business logic. It's also easier to scale out the app tier as you can bring app tier instances up and down easily via AWS vs having to copy a lot of data around to bring up a database replica.

yawaramin 10y ago
At the kind of scale you're talking about, I am pretty confident that 90% of people just won't need to do anything on that scale. For most people, business logic in the DB will serve their needs perfectly. And if some day they need to scale up to some level beyond a single DB, I'm also pretty confident that they'll have the resources to spend on a DBA consultant specialising in sharding or replication :-)

yawaramin 10y ago

> ... why not having Postgres itself serve web requests? At least two OSS backend stacks, PostgREST and PostGraphQL, are built on exactly this idea. And there's at least one commercial stack with the same idea: SlashDB.