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.
Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
21–30 of 42 posts
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#22What'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.
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#23We 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?
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#24This... 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.
To decouple this the person would have to broadcast nearly every event and rebuild the observer layers elsewhere.
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.
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#25Earlier quoted context omitted.
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 co…
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)
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#26We 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?
[deleted]
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#27This... 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.
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#28This... 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.
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.
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#29We 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?
The solution is to tax the rich. But we won't.
Re: Show HN: Pgclaw – A "Clawdbot" in every row with 400 lines of Postgres SQL
#30i love postgres and pgvector... this is exactly to my tastes
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.