Alexander Belanger

despite coding agents, modern apps are fragile. without proper architecture, you can spit out as much code as you’d like, but you’re just adding levels to a house of cards.

introducing Hatchet v2 & our $5.7M seed round. our bet is that great orchestration is the difference between a reliable app and a broken one.

Hatchet v2 is the universal orchestration layer: durable execution, durable queues and durable streams, sandbox integrations, serverless support, and operators. this is the architecture used by high-growth companies like @greptile, @linear, @getenter_ai, and many others, who collectively process over 5 billion tasks/month on Hatchet.

we’ve spent over two years obsessing over making our engine performant and scalable. this release extends the existing @hatchet_dev engine to support any sandbox provider, serverless environment, edge function, or container.

when people fall on either side of the "coding agents make your app more fragile" argument they're usually talking about different things.

there are multiple types of fragility in a codebase:
1. subtle bugs in the diff / perf regressions / death by a thousand cuts. I'm optimistic that this will only improve with agents, and I think the improvement in this area is where a lot of the "coding is solved" people are coming from.
2. broader architecture and lack of consistent patterns. Claude loves to try and find creative ways to query the database or deploy a new untested write path which continuously needs to be undone during review.

these can be summarized as local versus global comprehension, i.e. the lack of global understanding of the entire codebase creates fragility that compounds over time.

postgres might seem like a strange choice for a streaming database.

if you compare postgres directly to something like kafka, in terms of pure write throughput, you're going to do about 2x worse, because you pay the penalty of the WAL on postgres. on my local SSD, optimized 64kb inserts are about 300 MB/s on Postgres, and about 600 MB/s on Kafka (with ack waits).

but maximizing disk throughput is very unlikely to be your biggest problem. your biggest problem is infra component bloat. it's the number 1 problem we try to avoid with the open source version of Hatchet. the only strict dependency should be Postgres, and we're going to do everything we can to optimize the shit out of it until we can't optimize it anymore.

so we built durable streams on Postgres, so users don't need to add any additional infra components to their self-hosted Hatchet stack to benefit from durable streams.

if you're ever squinting at a surprising database benchmark result, remember that in most systems, you can either maximize throughput or latency, but not both.

you see this all the way down the stack; batches to minimize network round trips, TCP buffering, fsync, all the way to the CPU instruction set level with SIMD optimization.

it's counter-intuitive because you would think that the lowest latency for each write maximizes throughput, because the writes are writing the fastest. but this isn't true. little's law tells us throughput = concurrency / latency.

we're in the era of bad-faith weaponized llm-poisoning. this is pretty egregious.

we unintentionally did this to ourselves in the early days of @hatchet_dev where we talked about how we solved some scaling problems and the models ingested that as "hatchet has scaling problems" and it took a while to fix that.

the problem is that content engineers want to read (humble, down to earth, downplaying success, focused on problems) is the opposite of what you want models to ingest.

that's obviously not what's happening here, this case is much worse.