Hacker News

Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL

34 points by calebhwin ago | 26 comments
Hi HN,

Been hacking on a simple way to run agents entirely inside of a Postgres database, "an agent per row".

Things you could build with this: * Your own agent orchestrator * A personal assistant with time travel * (more things I can't think of yet)

Not quite there yet but thought I'd share it in its current state.

maxbond |next [-]

What's the advantage in putting agents in the persistence layer rather than the application layer? This seems to me strictly less flexible, scalable, secure, easy to work with... I am having a hard time imagining why I would want to integrate with APIs or write an agentic harness in the database rather than in application code?

Maybe I'm behind the times but I don't understand.

4ndrewl |root |parent [-]

It's similar to when we wrote all our business logic in eg pl/sql, stored procedures etc. Seems attractive at first, but it breaks separation of concerns, becomes difficult to test etc.

thatwasunusual |root |parent [-]

> It's similar to when we wrote all our business logic in eg pl/sql [...]

What do you mean with "when"? /s

I dread companies who still have logic in their databases when it's not necessary. <insert sad face>

tibbar |next |previous [-]

This is mind-bending. I can't imagine that it performs well enough to be particularly fit for production just yet but..... wow.

swyx |root |parent [-]

how exactly is adding a stored procedure as an agent mind bending

tibbar |root |parent [-]

I can only speak for my own mind ;) but the most advanced thing I'd seen prior in this regard was Google Sheets' =AI function, which is pretty convenient (if awkward) when you want to map values to LLM output.

What I specifically found "mind-bending" about this is that I don't have a clear concept of the limits of what an agent can do. In the limit case, it's basically like an independent employee, right?. So the concept of having a dedicated person sitting on each row of my database and transactionally performing any task I can describe is ... well, it IS a bit boggling to me.

Another way to look at it is: this is an extremely powerful construct for managing fleets of agents. I trust Postgres to execute all the stored procedures I ask it to. So with this tool I can easily spin up arbitrarily many agents. And state management is very simple, because they can directly edit their associated row!

IDK, the more I think about it the more fascinated I am. I'm sure there is some open source SAAS or something that has similar semantics and can do all this more efficiently, but now I know that this is a category of thing one could potentially build/use. Pretty nifty!

swyx |root |parent |next [-]

ok nice reply. i think i was where you were in 2021 around doing stuff in sprocs. i think pple generally follow a cycle of going overexcited about throwing everything in the database and then going "actually the database is a pretty bad production compute environment" and re-separating concerns back to different levels.

use sprocs lightly for simple fast stateless things. every other attempt at stuffing a lot of compute into the database that i'm aware of has basically failed to gain adoption (the personal awesomeness/happiness of the guy who created it aside)

debugnik |next |previous [-]

I don't understand why claw is a data type for columns in these examples, it doesn't seem to store any actual per-row state. Is it not possible to hook extensions onto "with" clauses or something similar?

wwweston |next |previous [-]

This... does not seem like separation of concerns.

Not to mention that the data layer seems like the one where you want to keep things most deterministic.

nkmnz |root |parent |next [-]

If you really want to run an agent on each created row, you could run this in a replica and stream the replies back to your system of record.

noupdates |root |parent |previous [-]

To decouple this the person would have to broadcast nearly every event and rebuild the observer layers elsewhere.

nkmnz |root |parent |next [-]

You could replicate and separate your llm-postgres from the system-of-record-postgres.

thatwasunusual |root |parent |previous [-]

And IMO that's what should be done.

Don't get me wrong, I like the idea and all that, but this is another pgsql "solution" that is tied to the database layer, when it should be in the application layer.

I like to be database agnostic, and while I prefer PostgreSQL on production, I prefer SQLite on the dev layer. You should never have to HAVE TO use a specific database to make your APPLICATION work.

ef2k |next |previous [-]

Nice. These are the kind of boundary pushing projects I like to see. It challenges assumptions of where application logic should live. The implications around cost, latency, and recovery are going to be interesting.

xnx |next |previous [-]

It feels like we're a week away from the Claw hype supplanting AI hype. Companies will start renaming things ClawX to get on the hype bandwagon.

maxbond |root |parent |next [-]

I think "claw" isn't appealing enough to be genericized and that "agent" will continue to be the generic term, but we'll see.

calebhwin |root |parent |previous [-]

It's just an abstraction people are excited about at the moment. Langchain was an exciting abstraction at one point.

My bet is we converge on a super minimal model<>computer architecture.

|next |previous [-]

readme |next |previous [-]

i love postgres and pgvector... this is exactly to my tastes

calebhwin |root |parent |next [-]

Same, it's in a similar vein as pgvector - probably not as performant as turbopuffer or chroma but you get the benefits of being in a really nice ecosystem.

tibbar |root |parent [-]

Is it? pgvector is primarily about indexing, I think? This feels more similar =AI in Google Sheets.

calebhwin |root |parent [-]

True though pgvector is not deterministic in a strict sense since HNSW is probabilistic.

cpursley |root |parent |previous [-]

Yes, and I imagine pgclaw would pair well with pgmq and pg_cron for scheduled work. Postgres really is enough: https://postgresisenough.dev

maxbond |root |parent [-]

Interesting to hear you say that, I was thinking (but hadn't said) that using WalEx to dispatch to some workers where the agent lived would be a better solution. The worker would then update the row (or more likely insert a new one in a different table with more constraints/different columns). I would be curious to hear what advantage you see in a `claw` type/`agent` column? I can't make heads or tails of it but I regard you as knowing a lot more about Postgres than me.

danr4 |next |previous [-]

this is fucking awesome

rel_ic |previous [-]

We need your help! Can you please use your creativity to build resilience to climate change in your community instead of experimenting with more ways to spend computing power?

|root |parent |next [-]

brunoqc |root |parent |previous [-]

The solution is to tax the rich. But we won't.