public inbox for [email protected]  
help / color / mirror / Atom feed
From: Guyren Howe <[email protected]>
To: Laurenz Albe <[email protected]>
To: PostgreSQL General <[email protected]>
Subject: Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
Date: Wed, 29 Apr 2026 15:42:31 +1000
Message-ID: <39f640d6-2a39-48c2-90b0-4adffe63bfc7@Spark> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>

Thanks for the feedback.

If you’re doing a small business application, running code in the database isn’t a concern.

If you’re doing a larger application, you’re probably sharding anyway. If you have more database servers and fewer web servers, is that actually an issue?

Updated the piece to discuss this.
On 28 Apr 2026 at 15:20 +1000, Laurenz Albe <[email protected]>, wrote:
> On Tue, 2026-04-28 at 13:24 +1000, [email protected] wrote:
> > Coming from a Rails/PHP/etc world. All of those communities generally hold that
> > the database should be treated as a dumb data bucket with all the logic in the middleware.
> >
> > I’ve long thought someone should write up what the alternative architecture using
> > Postgres to its fullest would look like. In order to differentiate it, I start from
> > the security advantages and work forward.
> >
> > I’d love to get some feedback on it. Harsh criticism is most useful… :-)
>
> No harsh critizism, but I am wary of all extremist positions.
> Just as I think that it is silly to keep the database as dumb as possible,
> I doubt that it is a good position to put all the smarts into the database.
>
> One obvious disadvantage is that if you put much of the processing into
> the database, most of the load will be on the database server, which is
> difficult to scale.
>
> Why not let each component do what it is best at?
>
> Yours,
> Laurenz Albe


reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
  In-Reply-To: <39f640d6-2a39-48c2-90b0-4adffe63bfc7@Spark>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox