You can, however, slap PRQL or KQL on top of Clickhouse.
https://clickhouse.com/docs/en/guides/developer/alternative-...
1.2 doesn't go into nearly enough detail to be convincing, in my opinion.
1.2 doesn't go into nearly enough detail to be convincing, in my opinion.
Personally I think this sentence summarizes the need pretty well: "Many telemetry systems have implemented their own DSL, and each tends to be tailored (intentionally or not) to the underlying data model and storage mechanisms.".
Also it's not like they've implemented a custom storage back-end, it's ClickHouse. ClickHouse itself thinks SQL is fine for querying time-series data (as do Snowflake and TimeScale, for that matter).
Ultimately of course Oxide can do what it wants, but the justifications provided in this doc are thin enough to make NIH seem like a very plausible explanation. Perhaps the problem domain is more complicated than just retrieving some time-series data out of ClickHouse, and the doc fails to make that clear.