Fork me on GitHub

@taylor.jeremydavid I have been looking at core2 - Will it be.backward compatible with the current XTDB? While it have a datalog style query capability as well as SQL? What about RDF?


Hey @U054219BT 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 for Prolog-style Datalog, or something like these for RDF:,

❤️ 2

I’m curious why you went with Calcite for the SQL interface rather than, say, a PrestoDB/Trino connector. They do fill somewhat different niches, but there’s a significant overlap in the bolt-SQL-to-something-not-relational functionality. My read is that Calcite is better at optimizing and making a system “look like” a SQL database, whereas Trino is better at integrating a system into a larger SQL ecosystem. (Also lots of things include Trino drivers.) Anyway, just wondering if that matches your take on it.


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.