“Modern” app development today usually presumes some element of “live updates” or “multiplayer” functionality. It’s usually handled only partially, in the app layer, with a good amount of spaghetti.
But the database to me seems like the place where this should happen. I should be able to
SELECT * FROM projects
WHERE owner_id=x
ORDER BY name desc
LIMIT 20
OFFSET 60;
and then I should be able to subscribe to any changes to that query.I should be able to have thousands of these subscriptions open at a time.
And ideally I should be able to get an efficient diff rather than a new result. Although a new result would be a great start.
I’m not sure why this isn’t seen as table stakes for databases in 2022. It seems like such a fundamental challenge of distributed application development.
https://altinity.com/blog/battle-of-the-views-clickhouse-win...
Disclaimer: I work for Altinity. Polyscale is a customer.
CREATE WINDOW VIEW IF NOT EXISTS minute_metrics_wv minute_metrics_tt AS SELECT ... FROM raw_metrics WHERE ... GROUP BY ...
That is, replacing the materialized view if favor of a WINDOW VIEWI think my ideal would be for the functionality to be baked directly into PostgreSQL.
Has anyone here used it?
Any comments on speed/scalability/reliability?
The self hosted license seems fairly permissive (Don't cluster, don't let your users manage the database views/queries [IANAL, read the license yourself]), but I'm hesitant given that I have never heard anyones stories about production use.
https://www.elastic.co/guide/en/elasticsearch/reference/curr...
More on the concept: https://en.wikipedia.org/wiki/Prospective_search
ClickHouse is used for computing Observability metrics within the UI. The automated caching algorithms do not use ClickHouse in any way. You can read more about the automation here: https://docs.polyscale.ai/how-does-it-work#caching-protocol or try the live demo here: https://playground.polyscale.ai/