logoalt Hacker News

zietoday at 11:43 AM3 repliesview on HN

We do the same thing, every employee can access our main financial/back office SQL database, but we just use PostgreSQL with row level security[0]. We never bothered to complicate it like the post does.

0: https://www.postgresql.org/docs/18/ddl-rowsecurity.html


Replies

orftoday at 12:04 PM

Back office, employee access is a completely different problem to what is described in the post.

How do you enforce tenant isolation with that method, or prevent unbounded table reads?

show 2 replies
lyjackaltoday at 2:41 PM

I want to build a shared postgres db with hundreds of small apps (OLTP) accessing shared tables using a RLS model model against well defined tables.

What are other limitations and mitigations folks have used or encountered to support stability and security? Things like

  - Query timeouts to prevent noisy neighbors
  - connection pooling (e.g. pgbouncer) also for noisy neighbors
  - client schema compatibility (e.g. some applications running older versions, have certain assumptions about the schema that may change over time)
show 1 reply
staticassertiontoday at 1:24 PM

I'd be so uncomfortable with this. It sounds like you're placing the full burden of access on a single boundary. I mean, maybe there's more to it that you haven't spoken about here, but "everything rests on this one postgres feature" is an unacceptably unsafe state to me.

show 5 replies