[rishav_sharan]

jasfi, I am actually following your project and wanted to take this moment to ask a couple of questions. How are you planning to solve for Postgres drivers/clients with async and pipelining support?

I had added nim std lib to the Techempower benchmarks, and while Nim shines in the plain text and other non db related requests, it comes at the very bottom as far as tests like Fortune go. When I did the work, there were no maintained/active Postgres drivers with async and pipelining support. And IMO, that wa the biggest reason why Nim hasn't had great benchmarking scores.

[jasfi]

Glad to hear you're interested in Nexus. The ORM currently uses db_postgres (from Nim's stdlib) only. I'm going to implement support for db_mysql and db_sqlite as well, it should be easy enough given how similar the API for the stdlib DB drivers are.

Actual work on DB drivers is out-of-scope for me though. I noticed there is an async Postgres driver available: https://github.com/treeform/pg. I don't know how well tested this driver is, and no mention of pipelining support.

It would be great to see Nim's web frameworks higher up on the Techempower benchmarks. Lack of such DB driver features usually comes down to time. The support for those features in stdlib would be a good bounty issue.

[prirun]

I did some testing with Nim a couple of years ago for HashBackup. Here's one of the db_sqlite issues I created:

https://github.com/nim-lang/Nim/issues/13559

I had much better luck with tiny_sqlite: https://github.com/GULPF/tiny_sqlite

[jasfi]

It seems that issue is now fixed. Either way, Nexus will soon support multiple DB drivers, and I'll work on making adding new ones relatively straightforward.

[rishav_sharan]

I went with db_postgres as well. Unfortunately, it is not async. I did consider treeform's pg, but unfortunately i did not get any reply from him on my question so decided not to go with it for the TE benchmarks.

I think the lowest hanging fruit for db drivers would be to just wrap libpq, the default PG driver. Given Nim's c interop, that should be easy. I was planning to do that, but then life happened and I had to skip that project.

I would say, that if you are trying to create a very involved framework, you should look to solve this problem. Otherwise the current perf of db_postgres can be a big deterrent to a lot of potential users.

[jasfi]

I agree that wrapping libpq sounds like a good idea.

[rishav_sharan]

did a bit more digging and apparantly db_postgres wraps libpq already. So either nim is still using a very old version of libpq or it was never updated to use the async apis.