jOOQ VS sql2o

Two good examples of "builders to SQL" are

https://www.jooq.org/

and

https://www.sqlalchemy.org/

JooQ isn't everybody's taste but I use it for my job and I think it's great particularly in that you can reuse expressions and write generators for complex queries. We have a powerful search interface that combines full-text with other kinds of queries ("Is about topic T", "Data was collected between S and E") that is beautiful. I think it's funny how JooQ has that lispy f(a,b) style (no accident it is like ferocity) and how Sqlalchemy is really fluent and takes advantage of operator overloading.

Relational databases provide components such as cursors, which can be used to process large datasets while fetching only a limited number of rows at a time. With the help of jooq framework,we can take it a step further—leveraging cursors under the hood while seamlessly integrating with Java's Stream API. Let’s see it in action!

(1) DSLs work great sometimes. See https://www.jooq.org/

(2) Elastic Load Balancer is a control loop responsive to workloads, that kind of thing is a commodity

(3) Under-provisioning is rampant in most industries; see https://erikbern.com/2018/03/27/waiting-time-load-factor-and... and https://www.amazon.com/Goal-Process-Ongoing-Improvement/dp/0...

(4) Anomaly detection is not inherently a problem of distributed systems like the others, but someone facing the problems they've been burned with might think they need it. Intellectually it's tough. The first algorithm I saw that felt halfway smart was https://scikit-learn.org/1.5/modules/outlier_detection.html#... which is sometimes a miracle and I had good luck using it on text with the CNN-based embeddings we had in 2018 but none at all w/ SBERT.

jOOQ would be one such example, https://www.jooq.org/

Not that I use this, I am a myBatis person in what concerns database access in Java, and Dapper in .NET for that matter, not a big ORM fan.

> 2. ORMs do not hide SQL nastiness.

This is certainly true!

I mean: ORMs are now well known to "make the easy queries slightly more easy, while making intermediate queries really hard and complex queries impossible".

I think the are of ORMs is over. It simply did not deliver.

If a book on SQL is --say-- 100 pages, a book on Hibernate is 400 pages. So much to learn just to make the easy queries slightly easier to type? Just not worth it.

I prefer jooq any day over ORMs. And dont get me started over what tools like Hasuna have to offer.

There are also some languages (forgot the names) that are SQL-done-right. Select in the back, more type safe, more logic, more in the same steps as the query gets executed. These need to be adopted by PG and MySQL and we're good to go. (IMHO)

https://www.jooq.org/

https://hasura.io/

See: https://github.com/jOOQ/jOOQ/issues/5916

Mostly i think because in our Kubernetes - the max resources allocated for single service instance - 2gb ram + 4vcore (2vcore, for 4 there is special agreement process). Under load i often see high memory pressure (gc count, high pauses, etc.). But handling http requests and dealing with CRUD is not a big problem. The huge difference appears during data batch upload into big-data system. The only service which was able to upload it's database faster than 300k record/s+ (peak ingestion) is using https://github.com/aaberg/sql2o + https://vertx.io/docs/vertx-pg-client/java/ . I don't remember numbers for services which use hibernate, but they mostly are very low.