Rust isn't inherently faster than C, but it can be easier in some cases for the optimizer to optimize Rust code better than C code. In particular, I have in mind Rust's reference types and the fact that they all "follow LLVM’s scoped noalias model"[1]. You can, of course, get this same benefit in C by using restrict, but most of the C code I've seen makes little use of restrict (and it's quite easy to accidentally alias a restricted pointer, so it definitely imposes a mental burden, even if it's very slight).

Rust's safety model allows you to get the optimization of C's restrict without the footgun. That can be a big win.

But of course, just because something is written in Rust doesn't mean it'll be faster than the equivalent C code. Rust isn't magic, after all.

[1]: https://doc.rust-lang.org/reference.html#behavior-considered...

Furthermore, given a team of experts working for half a decade on the rewrite, do we really believe it would yield safer code than if we spent the same amount of work on improving postgresql security?

I get the appeal of Rust for a new project though, especially if your team doesn't consist of seasoned C programmers.

Borrow checking means much less defensive copying without a loss of safety.

That's why I said potential. One reason would be the potential for much more asynchronous code than is easy to achieve in C, another would be Dev time. But the point is, rust is competing for speed with C, JS never was.