3 ms·

You can, however, slap PRQL or KQL on top of Clickhouse. https://clickhouse.com/docs/en/guides/developer/alternative-query-languages https://clickhouse.com/docs

You can, however, slap PRQL or KQL on top of Clickhouse. https://clickhouse.com/docs/en/guides/developer/alternative-query-languages https://clickhouse.com/docs/en/guides/developer/alternative-... 1.2 doesn't go into nearly enough detail to be convincing, in my opinion.

jsiepkes 2y ago
As far as I know neither PRQL nor KQL are DSL's intended for querying timeseries (like PromQL). Even other timeseries DB's like Influx DB which are somewhat similar to Prometheus have their own DSL (for example InfluxQL in case of influx DB). 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.".
- antonyt 2y ago
  KQL, at least, is exactly a DSL intended for querying timeseries. 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.