Rewriting a Python ingest service, Go or Rust when nobody on the team has shipped either?

I have ported the same class of service to both, about a year apart, so I can compare rather than speculate. The Go version took a fortnight for a first working cut and was in production in a month, and the code was boring in the way you want infrastructure to be boring. The Rust version was faster in the end and used noticeably less memory under load, but the first working cut took over a month, and most of that was not the borrow checker, it was choosing between ecosystem options for every single dependency and then discovering they disagreed about async.

If the workload were CPU bound number crunching I would say Rust and mean it. For pulling messages off a queue and shovelling them at a database, Go's standard library and one database driver gets you there and the performance difference will not be the thing that decides your event.

Go. Your ops team already runs Go binaries, which means deployment, observability and on call are solved on day one. That is worth more than any benchmark you will read this week.

Go, on the deadline alone. A competent Python developer is writing useful Go within a couple of days and reviewing it usefully within two weeks. Rust is a genuinely better language for several things you might care about later, and it is also a month of your six being spent learning when to clone and which async runtime you are in. Six weeks with a hard external date is not the project you learn a hard language on.

Mild disagreement with the framing rather than the conclusion. Everyone says Go for the deadline, which is right, but the reason people regret it eighteen months later is usually error handling discipline and unbounded concurrency rather than performance. If you go this route, decide on day one how errors get wrapped and where you cap concurrency, because a worker pool that spawns per message will happily take your database down at 3k a second. Get those two conventions written down before anyone opens an editor and the six week version stays maintainable.

Before you pick a language, work out where the four boxes are going. Ingest and write to Postgres is an I/O shaped workload, and if your Python is spending its time waiting on the network and the database, a rewrite in anything compiled buys you far less than you expect. Profile it for an afternoon first.

In my case the honest answer turned out to be that we were spending most of our CPU in JSON deserialisation and in building one INSERT per row. Swapping the JSON library and moving to batched writes cut our box count enough that the rewrite got deferred by a year. If yours is genuinely CPU bound in parsing then Go will help a lot and Rust would help slightly more, but find out which world you are in before you spend six weeks.

We picked Rust for a service like this with a team who had not written it before. We shipped four months after the six week estimate. Almost none of that was the borrow checker, which people warn you about and which you get used to. It was the long tail: picking an async runtime and finding a library that wanted a different one, compile times slowing the feedback loop to a crawl on a big workspace, and code review taking twice as long because two of us could not confidently review the third's code. The service has run beautifully ever since and I would still not choose that timeline again.