Re: Read-only connection mode for AI workflows.

On Tue, Mar 17, 2026 at 03:05:08PM +0100, Andrei Lepikhov wrote:
> On 17/3/26 14:52, Bruce Momjian wrote:
> > On Tue, Mar 17, 2026 at 11:04:25AM +0100, Andrei Lepikhov wrote:
> > > On 16/3/26 22:25, Bruce Momjian wrote:
> > > > On Mon, Mar 16, 2026 at 10:01:22PM +0100, Andrei Lepikhov wrote:
> > > > > > I do think the underlying problem of safely exposing databases to
> > > > > > automated agents is becoming increasingly common, so it seems like a
> > > > > > useful area to explore.
> > > >
> > > > I agree the need a read-only sessions is going to get more urgent with
> > > > MCP. Why doesn't the community code have a read-only session option
> > > > that can't be changed?
> > >
> > > The pg_readonly project aims to answer this question: if it is easy and
> > > cheap to implement as an extension, why do we need to touch the core?
> >
> > I think it is a fundamental feature the database should have by default.
> >
>
> Why wasn’t read-only mode set up like this from the start? - I haven’t seen
> any other DBMSs, aside from SQLite, offer this kind of guarantee.

I have no idea why. I guess there just wasn't much demand, but now
there clearly is with MCP.

> If we want to move forward, it makes sense to use a session parameter and
> add backend code to prevent violations.

Agreed.

> Postgres architecture looks well-suited for this feature. However, the
> request is to block all backend changes, not just the usual XactReadOnly
> limitations, but also things like vacuum, etc (temporary tables?). Should we
> also consider cluster-wide restrictions?

No, I don't think cluster-wide is in demand, but I might be wrong.

--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EDB https://enterprisedb.com

Do not let urgent matters crowd out time for investment in the future.