PUT .../cards/labels awaited a getCard per id and then an update per id. At the BULK_CARDS_MAX of 500 that is one thousand sequential round-trips for a single request, each starting only once the last one finished.

The reads are all the same question, so they are one $in query indexed into a Map. The writes genuinely differ - each card merges its own labelIds - so they stay individual updates, but they are issued together and awaited once instead of each waiting for the last.

Two details had to survive. The loop still iterates the caller’s cardIds rather than the query result, because a batch read comes back in the database’s order and without the ids that matched nothing: iterating it would silently reorder updated and lose notFound. And every write is awaited before the 200 is sent, so the response still means what it says.

The bulk DELETE beside it is deliberately left alone. Its per-card work is real

• cardRemover runs the sub-item hooks and each card gets its own activity - so batching the reads would save one query inside a loop that does far more than query.

Each user:, member:, assignee: and creator: predicate resolved its name with its own awaited findOne, so member:ann member:bob member:carol was three serial round-trips before the search could begin.

They are all the same question - which of these names is an account - so it is asked once, with $in, and answered from a map. A name typed under two operators is one lookup now rather than two.

An unknown name is still reported against the operator it was typed under: “ann is not a user” is not useful without saying where ann was typed.

FerretDB skipped every top-level $-key when building its WHERE clause, so a selector whose only SELECTIVE terms sit inside an $or produced a clause that narrowed nothing: SQLite returned the rows, and every one was decoded and filtered in Go to return a handful.

That is the shape of WeKan’s “which boards may this user see” query, and the worst possible one for it - archived = false and type = 'board' push down and match nearly everything, while the membership clauses that actually select stayed in Go. On an instance with ten thousand boards where a user belongs to five, that decoded ten thousand documents to return five, on every All Boards load.

It is all or nothing, and that is the whole subtlety. Every other pushdown NARROWS: a condition that cannot be expressed is dropped, the WHERE returns a superset, and the Go filter removes the rest. An OR that drops a branch REMOVES rows that match it, and the Go filter never sees them. So one unpushable branch refuses the whole $or, as does a nested-operator branch and an empty one.

See the FerretDB CHANGELOG for the database side.