- 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.
- 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.
- > 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>
- This is mind-bending. I can't imagine that it performs well enough to be particularly fit for production just yet but..... wow.
- how exactly is adding a stored procedure as an agent mind bending
- 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!
- 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)
- 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?
- 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.
- 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.
- To decouple this the person would have to broadcast nearly every event and rebuild the observer layers elsewhere.
- You could replicate and separate your llm-postgres from the system-of-record-postgres.
- 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.
- 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.
- 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.
- I think "claw" isn't appealing enough to be genericized and that "agent" will continue to be the generic term, but we'll see.
- 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.
- i love postgres and pgvector... this is exactly to my tastes
- 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.
- Yes, and I imagine pgclaw would pair well with pgmq and pg_cron for scheduled work. Postgres really is enough: https://postgresisenough.dev
- 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.
- this is fucking awesome
34 points by calebhwin 4 hours ago | 26 comments