Nice talk, you're a great speaker! And BTW I also love jOOQ :)

Your example translated to Permazen Kotlin (for concision) would be something like this:

    data class IncomeByDate(val film: Film, val date: LocalDate, val income: Long)

    films
        .flatMap { film -> film.rentals.map { IncomeByDate(film, it.date, it.amount) } } 
        .groupingBy { it.film } 
        .reduce { _, l, r -> l.copy(income = l.income + r.income) } 
        .values 
        .sortedWith(comparing<IncomeByDate, String> { it.film.title }.thenBy { it.date }) 

That's not using a convenience library like your jOOL.

You can argue against this in a bunch of ways. We could debate readability, the fact that it's not Java (doesn't matter technically) or that maybe the RDBMS parallelizes operations. We could add parallelism with a .parallelStream() in the right spot easily enough. But the query is around the same length as the SQL and reads in a similar fashion.

You discuss this a bit later but then say, look how much time we've spent! Sure, it comes later in your talk, but that doesn't equal time spent. You're comparing a SQL query you presented fait accompli, vs half a talk of iterating on the Java.

I think you probably overestimate how easy SQL is because you're an expert in it. For occasional users like me, it can be a quirky pain. Even the way strings work is unintuitive. But we know the standard libraries of our languages pretty well, we have to, it's required for the job. Your whole product is built on the fact that SQL isn't good enough, there's a lot of problems that remain unsolved when you just use SQL. Otherwise jOOQ wouldn't exist.

That's before we get into the different properties of the backends, e.g. horizontal read/write scalability for free (FDB) vs RDBMS, incremental online schema evolution and so on.