Our European takeover continues. We're so excited to have JB on the @hatchet_dev team!

We've gotten some great feedback already on our new overview page, excited to share it with everyone!

we're open sourcing a library we’ve been working on at Hatchet called pgoutbox. github.com/hatchet-dev/pgout… it implements a high-performance transactional outbox (specifically, for Go applications that use postgres via the pgx driver, but we'd like to make it available in other languages soon). we’ve been running it in production for the past 3 months at Hatchet, processing tens of thousands of messages per second. benchmarks on my local laptop have it going > 200k messages / second. what's a transactional outbox? it's a pattern for solving a lost-write problem in distributed systems. imagine a user signs up for your app and you’d like to create a new row in your users table and send them a welcome email. if your API crashes or restarts after you commit to the users table, but before sending a welcome email, the write to the email service is lost forever. so instead, you write the message to an outbox table as part of the same tx as the user write. obviously there’s a lot of intersection with task queues built on Postgres — transactional enqueuing is one of the main benefits! we had a few requirements that make typical task queue libraries a poor fit. first, it needs to support hundreds of thousands of different topics with exclusive consumers. this can get a bit tricky to scale due to MVCC on Postgres; if you attach a lease with a heartbeat to each topic, you’ll perform wayy too many updates and accumulate lots of dead tuples. second, it needs to support immediate message deletion with configurable retention policies per topic. this is quite different from a durable queue, where you’d like to preserve messages for future replays and auditing. third, it needed a solid scaling story and APIs built around batching. here for feedback / questions!

really excited for this one. this is the result of ~2 years of obsessing about one thing: performance. building a general-purpose workflow engine is a double-edged sword; it's great for developers and coding agents because you can use it to solve a bunch of different problems, but at the same time, users might run tasks using a mixture of features you've never seen before. you see this all the time with general-purpose databases, btw, like postgres -- super fast in most cases but if you use just the wrong combination of features it gets really slow and non-performant. so there were a few workloads on hatchet cloud which cost us an insane amount of $$$ to run. deeply negative margins. but rather than raise prices for these users, we basically just doubled down, then doubled down again, on improving performance. we've actually kept our infra spend pretty much flat for ~14 months, despite increasing revenue over 4x in that time period. better performance means less load on the databases, smaller spikes, and fewer machines. which leads directly to savings for users.

I asked Megan: why bananas? The answer: I feel like they're a silly fruit, I'm a silly person. There's no deeper meaning here. Enjoy!

We're getting close to releasing a new feature called operators, which enable Hatchet workers to run anywhere (not just a long-lived containers with gRPC support). Turns out that includes @useTRMNL e-ink displays! The entire Hatchet team is in Cape Cod for a hackathon, and I'd occasionally look over and see @vqtbl4q and @mnafees with a huge rig of TRMNLs rendering some crazy Rorschach-looking things. The video doesn't show this, but you can also register new TRMNLs as part of this rig and it'll synchronize and resize the bitmaps on each display. All of this synchronization is handled by the Hatchet serverless operator. Naturally, @mnafees also built a Hatchet dashboard into TRMNL, pictured below. We're working on getting this on the TRMNL marketplace soon!

This is one of those "break glass in case of emergency" features that we've gotten a bunch of requests for. Sometimes you'll just have large batches of work failing due to things outside of your control (Github down, Claude down, Azure down). Being able to temporarily pause a workflow until the issue is resolved will make it much less painful to dig out later. We also made it programmatic, so you could in theory build a nightly scheduler where you queue work throughout the day and unpause your workflows at night, to relieve pressure on your systems during peak hours. Excited to see this one released!

You can now run workers with a full Hatchet engine and a Postgres database running as a sidecar process. This took a long time to get right. Hatchet is a push-based scheduler. Work gets assigned by the engine to a worker, and gets sent over a network (gRPC) call to a worker. We made this choice after seeing the performance limitations of pull-based Postgres queues (based around FOR UPDATE SKIP LOCKED) as you add more queue requirements: global rate limits, concurrency and fairness strategies, etc. The Hatchet engine also handles things like RBAC, user management, tracking worker health, and internal maintenance that would require leadership election in a pull-based model. The tradeoff, of course, is that Hatchet runs separate from the worker process. Which is absolutely the right call in production, but makes local development and CI testing more difficult. While we were at it, we started experimenting with `embedded-postgres`, to remove another external dependency while still building on the Postgres we all know and love. Instantiating a client is literally a single function call. Some more docs here: docs.hatchet.run/v1/embedded