pg.ddx.io pgsql-general@postgresql.org mailing list archive
help / color / mirror / Atom feedDescribing the natural architecture for an internet-facing Postgres based app: feedback sought
5+ messages / 4 participants
[nested] [flat]
* Describing the natural architecture for an internet-facing Postgres based app: feedback sought
@ 2026-04-28 03:24 guyren@relevantlogic.com <guyren@gmail.com>
0 siblings, 2 replies; 5+ messages in thread
From: guyren@relevantlogic.com @ 2026-04-28 03:24 UTC (permalink / raw)
To: pgsql-general
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… :-)
lydb.xyz/zero-authority-architecture <https://lydb.xyz/zero-authority-architecture/>=
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
@ 2026-04-28 05:20 Laurenz Albe <laurenz.albe@cybertec.at>
parent: guyren@relevantlogic.com <guyren@gmail.com>
1 sibling, 1 reply; 5+ messages in thread
From: Laurenz Albe @ 2026-04-28 05:20 UTC (permalink / raw)
To: guyren@relevantlogic.com <guyren@gmail.com>; pgsql-general
On Tue, 2026-04-28 at 13:24 +1000, guyren@relevantlogic.com 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
@ 2026-04-29 05:42 Guyren Howe <guyren@gmail.com>
parent: Laurenz Albe <laurenz.albe@cybertec.at>
0 siblings, 1 reply; 5+ messages in thread
From: Guyren Howe @ 2026-04-29 05:42 UTC (permalink / raw)
To: Laurenz Albe <laurenz.albe@cybertec.at>; pgsql-general
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 <laurenz.albe@cybertec.at>, wrote:
> On Tue, 2026-04-28 at 13:24 +1000, guyren@relevantlogic.com 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
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
@ 2026-04-29 07:54 Laurenz Albe <laurenz.albe@cybertec.at>
parent: Guyren Howe <guyren@gmail.com>
0 siblings, 0 replies; 5+ messages in thread
From: Laurenz Albe @ 2026-04-29 07:54 UTC (permalink / raw)
To: Guyren Howe <guyren@gmail.com>; pgsql-general
On Wed, 2026-04-29 at 15:42 +1000, Guyren Howe wrote:
> 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?
No, but sharding is absolutely non-trivial. Your application has to be designed
for it, and your data must be so that they can be split across shards with as few
interconnections as possible. Spinning up more application servers is much easier.
Yours,
Laurenz Albe
^ permalink raw reply [nested|flat] 5+ messages in thread
* Re: Describing the natural architecture for an internet-facing Postgres based app: feedback sought
@ 2026-05-01 20:27 Merlin Moncure <mmoncure@gmail.com>
parent: guyren@relevantlogic.com <guyren@gmail.com>
1 sibling, 0 replies; 5+ messages in thread
From: Merlin Moncure @ 2026-05-01 20:27 UTC (permalink / raw)
To: guyren@relevantlogic.com <guyren@gmail.com>; +Cc: pgsql-general
On Mon, Apr 27, 2026 at 9:25 PM guyren@relevantlogic.com <guyren@gmail.com>
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… :-)
>
> lydb.xyz/zero-authority-architecture
>
I have been developing in this style for many years. Application requests
in JSON/JSONB, and zero IQ middleware outside of caching, transport
authorization, etc. Prior to JSON, I was doing it with composite types --
postgres has been able to do some variant of this since mid 8.x series. I
can assure you, this style of architecture works, your core assumptions are
mostly correct, although I'd gently suggest taking a broader view on
application architecture vs authorization. Generally speaking, it is a
very fast way to write robust applications quickly, and I've written highly
scalable enterprise applications in this style.
I'm not afraid to take things to the extreme. If you want to see examples
backend rich coding in action, take a look at pgasync
<https://github.com/merlinm/pgasync; and especially pgflow
<https://github.com/merlinm/pgflow;, which is a airflow style orchestrator
written in a stored procedure daemon :-).
merlin
^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-05-01 20:27 UTC | newest]
Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-04-28 03:24 Describing the natural architecture for an internet-facing Postgres based app: feedback sought guyren@relevantlogic.com <guyren@gmail.com>
2026-04-28 05:20 ` Laurenz Albe <laurenz.albe@cybertec.at>
2026-04-29 05:42 ` Guyren Howe <guyren@gmail.com>
2026-04-29 07:54 ` Laurenz Albe <laurenz.albe@cybertec.at>
2026-05-01 20:27 ` Merlin Moncure <mmoncure@gmail.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox