the orchestration engine for everything async: ai agents, background tasks, pipelines. billions of tasks run, from the fortune 100 to cursor, greptile, enter
it's been a week. to end it on a high note, we're releasing FIPS-compliant images for everyone (not gated behind some enterprise sales maze).
you're either in one of two camps: you've never heard of FIPS, or you deal with it every day. this is for the second camp.
docs: https://t.co/agBSTiJ9G5
C++ was the first language I learnt and abstractions were quite important from day one. The way objects can mutate their way to various identities and the compiler makes it all work is one of the beautiful ways of reasoning about writing useful code, something that OOP languages brought with them.
If you're building a startup today, one of the core strategies to become a winner in your space is to build a platform with abstractions and primitives that scale across various use-cases. I tend to always think on these lines given my early intro to programming with languages like C++ and Java.
So naturally, I love working at @hatchet_dev where we are building the orchestration engine to power every workload out there. The primitives we have built over the time have been extremely powerful to provide our users with an abstraction layer over all of their running workflows and jobs, ranging from AI agents to data pipelines and even notification systems.
please join us in welcoming jean-baptiste souvestre to the team! based in paris (ooh-lala), JB joins our growing engineering squad in europe. 🥖🇪🇺🍷
we asked him some questions to get to know him better, here's what he said:
➡️ light mode or dark mode?
🎤 what is a light mode?
➡️ we're told you're a cat man. tell us about your cats.
🎤 so i have 3 cats, kiki, chablis, and croche-pattes, all of whom are scoundrels in one way or the other. they love wet food, waking up at 4pm, and going to bed at 5.
➡️ how did you first come across hatchet?
🎤 i wanted to introduce hatchet to my last company because i liked the tech that much, but i figured it might just be more fun to work on it directly.
➡️ if i were in paris for one (1) day and wanted to get the best croissant, where would you suggest i go?
🎤 that's mamiche, in the 10th arrondissement, for sure.
➡️ what's something that surprised you in your first week here?
🎤 honestly can't decide between the tech maturity at such a young startup and the amount of custom frog emojis one can add to slack.
➡️ last, but not least: claude code or codex?
🎤 claude, but just because it was a french first name.
bienvenue à bord, JB! 🚀
our new overview page 1) is great for observability over your workflow orchestration; and also 2) offers relief from the sisyphean burden of shame and guilt over limited metric visibility that we all must carry as we roam this mortal coil. it's great
WE have a NEW overview page 🧨 🧨 🧨
that's right, you read that correctly, hatchet now has a fancy, brand-spankin'-NEW (!!!!) ~ overview page ~ that shows you ALL the stats you might need to know
a key executive #stakeholder flagellating you because the 10 thousand worker pods you provisioned them are sitting idle? point them at the overview page (100% utilization, now that's what i call efficiency!!) and tend to your wounds 📈
#synergy
we're open sourcing a library we’ve been working on at Hatchet called pgoutbox. https://t.co/sDcaCS9zlG
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!
our cto has a way with words ...
... he is not wrong though; but i'd call us efficient rather than cheap :) and all that efficiency work allows us to pass on (some of the) savings to customers
https://t.co/Ai0zUEWQFk