Topics discussed:

• Evan's argument is that CQL and SQL are both ways of writing relational algebra, so one translates into the other mechanically — his pipeline goes CQL to relational algebra, then to a ViewDefinition, then to whatever SQL dialect you want, with the CQL-specific quirks patched in last so each dialect's own features can still be used.
• Going straight from ELM to SQL is the obvious approach and it fails: emitting any given piece of SQL keeps needing context from somewhere else in the tree. The algebra layer exists so you can see the whole query before you write a line of it.
• The scaling problem has a specific cause. A measure written in context Patient answers true or false for one patient, so you run it a patient at a time. context Unfiltered drops the implicit patient join — from Condition then means every condition for everyone, and the numerator comes back as a list of patient IDs. Any measure can be converted automatically, and Evan's view is that one-at-a-time should never have been the default.
• Early numbers on DuckDB: single-digit microseconds per bundle, roughly a million members a second, against an industry target of about a millisecond per member on CQL engines.
• On letting AI do the translation instead: fine for a simple measure, falls apart on a hard one. CQL's date and interval rules are subtle enough that the model ping-pongs between getting the general case right and getting the edge cases right. Evan's conclusion was that if you are going the AI route you may as well skip CQL and translate from the written spec.