Hey @U054219BT https://github.com/xtdb/core2 is currently a very separate thing (separate repo) because it's highly experimental and we didn't want to couple too many decisions together. For the time being we are busy trying to nail down the SQL UX and basic usability (join performance, operations etc.) before committing further energy and diverting focus to other aspects like additional APIs and compatibility. Somewhat related, I have been exploring and toying with a few compile-to-SQL projects to understand the current boundaries of Core2's SQL support, e.g. using https://github.com/EvgSkv/logica for Prolog-style Datalog, or something like these for RDF: https://github.com/Quetzal-RDF/quetzal, https://github.com/SmartDataAnalytics/Sparqlify

Hey @U050N4M9Z this is a great question. IIRC the biggest reasons were: 1. fewer moving parts - we didn't want to introduce new components and servers into the architecture, and instead preferred the idea of having something in-process that looked like other XT modules 2. Calcite felt approachable, with tonnes of examples in the wild to study, and the mapping to XT's Datalog seemed within reach

> Trino is better at integrating a system into a larger SQL ecosystem I suspect this is true, but I would guess also requires Trino being 'sold' into the organisation in isolation from XT (I may well be wrong though!). In any case, if we'd had any prior experience with Trino at the time I can well imagine the decision being different.

That all makes a lot of sense, yep. If the team(s) are already used to working with Presto/Trino/Athena then it’s definitely an easier sell. In some cases it may even be something as trivial as “we already allow the Trino JDBC driver, never heard of this Avatica whatsit.” Thanks!

It occurs to me that technically you could even use the Calcite engine inside a Trino connector, but that might get very confusing if you weren’t careful.