This has been discussed in multiple working group calls and we have some sub-tasks tracking this, but no parent issue that I could find. So, here's the context all in one place.
Druid currently provides a useful UI on top of the underlying OLAP database, but we've heard that its complexity may be a blocker for adoption—and that current adopters are in favor of removing it. Bluesky has removed Druid in favor of BigQuery in their downstream deployment of Osprey. #95 (comment)
It's been mentioned that leaning on Clickhouse (with its bare bones UI) or using Grafana as a UI over whichever data store could be alternative approaches. #95 (comment) Postgres and timescaleDB have also been brought up.
We've mentioned that we plan to have a product designer take a look at Osprey to see how we could abstract the visualizations from Druid to work with other backends. #123 (comment)
We'd need to write AST from SML to whatever db is swapped in. #142 (comment)
This has been discussed in multiple working group calls and we have some sub-tasks tracking this, but no parent issue that I could find. So, here's the context all in one place.
Druid currently provides a useful UI on top of the underlying OLAP database, but we've heard that its complexity may be a blocker for adoption—and that current adopters are in favor of removing it. Bluesky has removed Druid in favor of BigQuery in their downstream deployment of Osprey. #95 (comment)
It's been mentioned that leaning on Clickhouse (with its bare bones UI) or using Grafana as a UI over whichever data store could be alternative approaches. #95 (comment) Postgres and timescaleDB have also been brought up.
We've mentioned that we plan to have a product designer take a look at Osprey to see how we could abstract the visualizations from Druid to work with other backends. #123 (comment)
We'd need to write AST from SML to whatever db is swapped in. #142 (comment)