Hatchet

We're hosting an intimate happy hour in SF next week with our friends at @NangoHQ for AI CTOs and engineering leaders. 🍺 Thursday March 26 6-8pm Mission District DM @abelanger5 for the details. 📩

Checkpointing your AI agents is important. (Sundance hasn't called us back yet.)

If you're building AI in SF, we have a few spots left and would love to see you there. Reach out for the details!

Some of the most interesting conversations I've had recently have been with AI builders on the future of agents. We'll be discussing that and more at the @NangoHQ and @hatchet_dev happy hour next week. There's a few more open spots, DM me if you're interested in joining!

Six months ago, we saw a huge spike in @hatchet_dev usage (which is great) but then we started to see an issue. Our Postgres instances were running out of storage faster than we could resize our database, shooting over our 80% disk usage and creeping up over 90%. We knew it would take over 6 hours to cut over to a larger instance, which meant that our database would crash before the cutover was completed. This is a symptom of the particulars of our infra stack, which needs to balance really fast task execution paths with storing very large amounts of data (over 50TB in just our Oregon region) in the form of task payloads. We use NVMe disks to make our Postgres queries incredibly fast, but these aren't networked disks, so swapping the disk out requires provisioning an entirely new database. Luckily for us, when this usage spike happened, we had already implemented a failsafe: immediate offloads of payloads to S3 so disk space would stop increasing on Postgres. This was implemented on S3 Express One Zone for milli-second level reads and writes. But we knew this wasn't a good long-term solution (limited support for express one zone in regions, regular S3 is far too slow, and S3 PUT requests alone would cost us tens of thousands of dollars per month). So we started building a multi-tier storage architecture, where "hot" payloads stay on our NVMe disks while cold payloads are batched and flushed to S3. Since most of our Postgres payload data exists in TOAST tables, we affectionately call these "supertoast" tables.

@abelanger5 @gabe_ruttner

Quick Monday morning win: @hatchet_dev had more active users last week than ever before. We've also doubled the number of self-hosted installations compared to 3 months ago. 🤯 Excited for launch week at the end of this month!

@akkkkiira @ArgaLabs

pic of @ArgaLabs team feeling the yc community before the batch even started, thanks @hatchet_dev !! Quick pie break & back to building :)

Check them out and let us know what you think! docs.hatchet.run

Drumroll please. 🥁 We re-wrote our docs! Yes, all of them. Each page written by an actual human for the (human) developers who will read it. Some highlights: 🤖 Coding agent quickstart (Cursor, Claude Code, and more) 🧑‍🍳AI agents cookbook - reasoning loops, routing, multi-agent, parallelization ➰Human-in-the-loop patterns 👷Updated core concepts - tasks, workers, and durable workflows

We've spent 2 years trying to get @hatchet_dev's docs right. We might have just done it. Our philosophy: if we expect humans to read the docs, a human should write them. Nothing is worse than trying to figure out what a product does and being greeted by a mountain of listicle AI slop. Unfortunately, that makes us (the founders + engineers) the bottleneck. We've wanted to use AI to help solve this problem for years but hadn't tried one that really worked. This week, we tried @promptlessai and it finally clicked. We write the content, Promptless ensures it's up-to-date and correct by running against every PR. Congrats @prithviramak on a great product!

nicest gesture from anyone during the batch? warm apple pie handwritten note cmon tyvm <3 @abelanger5 @hatchet_dev

@MRadhuber @abelanger5 💙💙💙

Welcome to the team, Julius!

So excited to welcome Julius Park to @hatchet_dev! 🪓 We're a small team by design (Julius is our 4th hire) and look for colleagues who are humble, ambitious, curious and kind, motivated by difficult problems and eager to learn. We also have an ambitious roadmap. Julius will be a valuable addition as he focuses on contributing to the core product full stack. 🚀

Here’s what’s new in Hatchet 🪓: 🦀Run tasks in Python significantly faster with improved serialization performance in Rust 👉Access task context from anywhere with new helper

as a @cursor_ai fangirl, the latest @hatchet_dev product update is particularly exciting 🚀

We've started using coding agents more in our development lifecycle and honestly, @hatchet_dev was really difficult to use with them. Engineering teams building with Claude Code and Cursor expect their tools to fit natively into that workflow. So we fixed it.