rust-postgres VS FrameworkBenchmarks

For C there should be good options.

For Rust it doesn't appear that well-supported.

A very simple approach is to poll for changes using `pg_logical_slot_get_changes()` - that should work with any driver. That's what I used for my initial experimentation, before switching over to the streaming replication protocol for better performance.

The streaming replication protocol is not that complicated, but currently you'll have to handle some of the low-level protocol yourself, or work with some very experimental implementations. There's a project to help get you started at [1], and some more discussion at [2].

For the logical decoder, wal2json is quite nice to experiment with, but I've found pgoutput is not that complicated and gives you something closer to the raw data.

[1]: https://github.com/seddonm1/logicaldecoding/

[2]: https://github.com/sfackler/rust-postgres/issues/116

This is a bit of a rant so please bear with me. I wrote a small utility program a long time ago that used this version of the postgres crate

En este post aprendermos a usar Rust, Tonic y la crate gRPC, y implementaremos un CRUD con Postgresql database.

I can understand that this can be frustrating and I know that the situation there is not ideal for diesel. There are certainly things to improve there by either providing a bundling support which builds the native library as part of the normal build process or by implementing a pure rust connection implementation. Both is possible with diesel, but requires some work. At least the pure rust connection implementation is something that can be provided by a third party crate now with upcoming diesel 2.0 release. If you are interested in that checkout this and this issue. As for the bundling support: This requires changes in the mysqlclient-sys and pq-sys crates. Again help there is welcome. In the end it makes me sad that some people have repeating decided that a solution to this problem is to write just another crate instead of helping to fix these issues. This just results in everyone have more work to do, as there are now two non-perfect solutions instead of having one slightly improved solution.

We created this little library to have a fully native type for Postgres Numerics with the rust-postgres (https://github.com/sfackler/rust-postgres) library.

The problem with a crate like postgres is that you have to define the types of the query at compile-time. And if you use the simple query protocol in postgres, you just get a bunch of strings, i.e. no proper typing at all. However, for maximal flexibility arbitrary queries should work in pigeon, without knowing the database schema.

Some nifty things about usual: - It's a generic wrapper over any SQL "row" object. The first implementation that's provided is for tokio-postgres, but traits are available to implement over whatever you'd like. - It provides static typing for partial queries. That is, it supports fetching a subset of fields from a row and makes a unique type for the return value. This gives you some neat-o type safety like this:

In this post, we will learn how to use Rust Tonic gRPC crate. We will learn how to implement CRUD with Postgresql database.

(see: https://github.com/sfackler/rust-postgres/blob/e15c9b1415f69821799f1370246581c1600a6196/postgres-protocol/src/types/mod.rs#L137)

That was a ballpark estimation, and while pure req/sec is usually irrelevant, it still comes in when the load starts to increase and you need to squeeze every last drop of perf.

PHP usually is doing poorly, even with its "cache", and when you realize that PHP devs actually are not PHP devs, but framework (like laravel/symfony) devs you need to account for the overhead of the framework too.

But you can have a look at the framework benchmarks game:

https://www.techempower.com/benchmarks/#section=data-r21&hw=...

This run has .NET 9 in: https://www.techempower.com/benchmarks/#section=test&runid=e...

> that Rust/WASM is likely to become the go to stack for complex web apps

What kind of apps?

On the backend there are plenty of mature ecosystems already that have been around for decades. Even focusing only on performance there's not a huge difference with say .NET or Java when looking at web benchmarks like TechEmpower[1].

On the frontend nothing can really beat the DX of using Vite with JS (hot reload of JS components, styles, etc). I don't know if it's even possible to get hot reload with WASM.

I could be wrong but it sounds like doing a complex web project in Rust would be a pain with not a lot of benefits over more popular and mature solutions.

[1] https://www.techempower.com/benchmarks/#hw=ph&test=fortune&s...

This seems a bit unfair to JavaScript. There’s a lot of optimizations made to the language and its runtimes that have made a more than viable choice for server side applications over the years. The JavaScript that started as a Webbrowser client side language is very different from the ECMAScript that we have today. Depending on its usage it can also be one of the fastest, only regularly eclipsed by rust[1]. So no, JavaScript really isn’t a bad option for server side applications at all.

[1] https://www.techempower.com/benchmarks/#hw=ph&test=composite...

Is it? Asking as someone not very tuned into the ecosystem. Based on TechEmpower's Web Framework Benchmarks[0] and AreWeWebYet's resounding "yes!" for years now[1] I always got the impression that there were quite a few options available.

Rocket, Actix, Axum, Salvo, etc just to name a few. Each with different focuses (e.g. performance vs "batteries-included-ness")

[0] https://www.techempower.com/benchmarks/#hw=ph&test=composite...

[1] https://www.arewewebyet.org/

> The database pool needs to be at 512 to 1024? Yet Rails seems to get away with far less than that and still have better performance.[2]

Rails concurrency model is per process. So the size of your connection pool will be 3 multiplied by the number of workers.

Second of all, the database pool needs to be 512 or 1024 if your app server can push traffic quickly enough to the database. If you are increasing the Rails pool size and it is not getting faster, then Rails is your bottleneck. My working theory based on the runs I did last week, is that the pool is the bottleneck in Elixir's case. We will see in a couple weeks once the new PRs land.

> If these people can't get good results in tuning Elixir, who can?

Just look at the current results from main: https://www.techempower.com/benchmarks/#section=test&runid=1...

If you want to compare with Rails in particular, we beat Rails in every benchmark except two:

1. Single query: which will be tackled by better sizing our pools

2. Plain text: where we are currently sending the wrong payload (but when we sent the proper payload, we beat Rails too)

My point is exactly that the feedback cycle is long, so it takes time, and I was not able to invest time before. But given how intent some folks are to misrepresent benchmarks (and assign malice to the whole community), it is probably better to continue looking into it.

I share your sentiment but Swoole is an async event loop implementation for PHP.

It's relatively fast. Like 300k req/s on an old intel i5 with 4 cores fast.

https://openswoole.com/benchmark

Or 40% of top Tech Empower speed in composite score: https://www.techempower.com/benchmarks/#hw=ph&test=composite...

We have been using ruby extensively through our org for years.

We tried java, go, node, elixir, python.

Pretty much it comes down to ruby on rails have a very opitionated way of doing things.

We mix some DDD and recently High Performance PostgreSQL for Ruby on Rails https://www.amazon.com/dp/B0CX876RLY

It is slow. How much? According to tech empowered https://www.techempower.com/benchmarks/#hw=ph&test=query&sec... something like 6 times slower than java-vertx-postgres

Me moved to rails and flutter to have a quick coding hot-reloading loop

And we determined it was easier for our devs to all master a tool, instead of jumping between frameworks and DBS (we use rails, Kamal, postgres, redis and clickhouse, datadog)

The result has been awesome. Our web pages pass Google pagespeed in green, we serve millions of requests a day without issues, datadog APM helps a lot and they move between projects easily. The have hotspots like query autocompletion in one of our sites, which we do in memory with a true library which runs a C library underneath for under 100ms response times.

If your org is competing in a really really competitive field and you need to reduce costs to zero (as whatsapp had to do with Freebsd and erlang) go ahead and do your tradeoffs. But if you don't, rails is the one man army framework. Even more with hotwire.