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.