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

2/12/2026 at 7:32:56 PM

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.

by maxbond

2/12/2026 at 7:52:47 PM

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.

by 4ndrewl

2/12/2026 at 9:00:06 PM

> 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>

by thatwasunusual

2/13/2026 at 2:45:16 AM

The real fun begins when you encounter a system where someone thought it was a good idea to store source code in the database rows.

by SOLAR_FIELDS

2/13/2026 at 4:42:52 PM

What does it mean to put an agent inside of a PG DB? Is PG doing the actual computing/inference (does it tie to GPU), or is PG just storing the state of the agents neural net (is that a thing, it seems like it would be).

Maybe I'm strictly too stupid to even parse the concept, but I don't understand what I'm looking at one bit.

by jmaw

2/12/2026 at 6:58:50 PM

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

by tibbar

2/12/2026 at 7:39:45 PM

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

by swyx

2/12/2026 at 8:42:48 PM

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!

by tibbar

2/12/2026 at 9:09:23 PM

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)

by swyx

2/13/2026 at 3:06:43 PM

Oh, like, I wouldn't actually use this specific implementation. I used to work at a shop with thousands of lines of Oracle triggers that you had to edit inline in the web browser with no version control and I shudder to think of returning again.

I'm more interested in the data flow. exa.ai got famous for promising search with massively parallel execution of LLMs on candidate results. In practice, it's never worked that well for me, but the model is very cool and has worked for me e.g. in open source work, searching for bugs across files.

Mapping N items to "N agents with state" feels like an absurdly powerful construct to me. Maybe this is just a well-known pattern that everyone has seen already, but given how much better agents have gotten in the past year, crossing the threshold from "toy" to "arguably superhuman" on many tasks, I think it just hits different.

by tibbar

2/13/2026 at 5:30:49 PM

ok gotcha. yeah i guess my background with temporal.io got me used to "every workflow instance can have a shit ton of long running state that gets persisted and rehydrated at will". check those out if you like N:N+state, whether or not it includes agents is an impl detail

by swyx

2/13/2026 at 9:37:15 PM

Haha, I guess we see this in reverse: I see the specific framework as the implementation detail (I use, and enjoy, temporal!) I think it's the part about automatically launching a metric ton of agents that is (to use the term again) mind-bending to me.

by tibbar

2/12/2026 at 10:26:04 PM

[flagged]

by renato_shira

2/12/2026 at 7:09:26 PM

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.

by wwweston

2/12/2026 at 9:21:27 PM

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.

by nkmnz

2/12/2026 at 7:34:47 PM

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

by noupdates

2/12/2026 at 9:22:47 PM

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

by nkmnz

2/12/2026 at 9:05:40 PM

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.

by thatwasunusual

2/12/2026 at 8:20:56 PM

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?

by debugnik

2/12/2026 at 9:00:31 PM

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?

by rel_ic

2/12/2026 at 9:26:16 PM

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

by brunoqc

2/12/2026 at 11:30:34 PM

Until YOU get rich.

by worldsavior

2/12/2026 at 7:23:52 PM

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.

by xnx

2/12/2026 at 7:36:33 PM

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

by maxbond

2/12/2026 at 7:28:12 PM

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.

by calebhwin

2/12/2026 at 8:56:33 PM

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.

by ef2k

2/12/2026 at 7:01:26 PM

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

by readme

2/12/2026 at 7:07:39 PM

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.

by calebhwin

2/12/2026 at 7:10:05 PM

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

by tibbar

2/12/2026 at 7:26:30 PM

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

by calebhwin

2/12/2026 at 8:36:44 PM

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

by cpursley

2/12/2026 at 9:47:02 PM

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.

by maxbond

2/13/2026 at 12:44:19 AM

You could probably use listen/subscribe trigger to accomplish that.

by cpursley

2/12/2026 at 7:17:47 PM

this is fucking awesome

by danr4

2/13/2026 at 12:56:31 PM

[dead]

by mergisi

2/13/2026 at 8:05:30 AM

[dead]

by cboyardee