[kleebeesh]

Looks neat, but wasn't this the promise of Presto? Presto didn't seem to really work out. From what I've seen it converged to a mostly analytical engine. It's still very useful, but I've never seen it used (successfully) in an OLTP workload. Maybe there's some difference in the intended product trajectory that I'm overlooking here?

[WaxProlix]

AWS's Athena uses Presto to pretty good effect, though I guess you could say those use cases are largely relegated to analytical purposes.

Back in my consulting days, I built a distributed query system based on Presto to integrate some custom/onprem data sources with more distributed/cloudy ones, Hive and such, and it worked well for that, too. Most of that was also ad-hoc, batch, or event-driven analytics, too, but there were plans for supporting production workloads.

I think maybe one reason people shy away from things like Presto (and the above) is the uneven performance guarantees; waiting for an unoptimized Hadoop or Orcfile query by accident because you joined on something or another is fine for one-offs, but might become costly in prod workflows.

[kleebeesh]

> I think maybe one reason people shy away from things like Presto (and the above) is the uneven performance guarantees; waiting for an unoptimized Hadoop or Orcfile query by accident because you joined on something or another is fine for one-offs, but might become costly in prod workflows.

Right, so my question is: how is that solved with Hydra? Seems like you'd arrive at the same issue?

[buremba]

Presto is pretty successful but its focus is to be distributed query engine, not a proxy layer for the existing query engines. We use Trino ( formerly Presto) as our query layer and do something similar to Hydra at Metriql [1] with a fairly different use-case. Data people provide a semantic layer with the mecrics and expose them to 18+ downstream tools.

[1]: https://metriql.com