This +1. I've been burned before when using ORMs which translate simple-looking queries to terribly inneficient SQL statements underwater.

Yeah I’m a web dev, and recently I found out the most popular JS ORM doesn’t produce joins. It’ll just execute multiple queries in sequence. I don’t know how common that is in the ORM landscape but for me that’s a deal breaker.

That’s just a direct result of lazy loading — if you don’t grab the related objects in the initial query, then there’s no joins to be had.

Most ORMs do lazy loading by default, but also have a way of doing eager loading — either requiring the nested object to always be loaded as well, or dropping down to some pseudo-sql.

In c#/EFCore, I always prefer to avoid lazy loading and just write LINQ, and just use the ORM to map the resultset back to objects

Common enough to have a name: the N+1 query problem.

1+N is clearer I think, and what I remember seeing in the past - it matches what's actually happening with this problem. First time I saw N+1 sometime around a year ago, I had no idea it referred to the same thing and thought it was something different.

N+1 looks like an issue with aggregation after a parallel run, something I've encountered with celery tasks before.

For reference, this is the output:

    WITH table_1 AS (
      SELECT
        customer_id,
        total,
        total - 0.8 AS _expr_0
      FROM
        invoices
      WHERE
        invoice_date >= DATE '1970-01-16'
    ),
    table_0 AS (
      SELECT
        COALESCE(SUM(_expr_0), 0) AS sum_income,
        customer_id
      FROM
        table_1
      WHERE
        _expr_0 > 1
      GROUP BY
        customer_id
      ORDER BY
        sum_income DESC
      LIMIT
        10
    )
    SELECT
      c.customer_id,
      CONCAT(c.last_name, ', ', c.first_name) AS name,
      table_0.sum_income,
      version() AS db_version
    FROM
      table_0
      JOIN customers AS c ON table_0.customer_id = c.customer_id
    ORDER BY
      table_0.sum_income DESC