Some general points: • Presto is ill-suited for low latency lookups of a single object, so that will never be competitive. • There is likely an inflection point where Presto will win, at a much bigger database size than what you are describing. • We are aware of substantial opportunities to improve performance on queries, so this will get better in a future release. All that said, we would be happy to learn more about your use case and see if there are ways to make it faster today.

Thank you @U072WS7PE 🙂 What do you need to learn more about our use case?

We're building a POC for a customer with Datomic and their existing BI tools rely on SQL and they also use it for manual queries as well. So we're investigating using Datomic Analytics so the customer can evaluate it

@U0AD3JSHL You can share these details with me via support ticket (<mailto:[email protected]|[email protected]>), but we would be interested in where specifically you encounter performance issues and what your specific POC business requirements are. Using presto/trino clusters and tuning we have found we can tune performance well (adding more nodes for parallel work). As Stu said we are aware there are substantial opportunities to improve performance of queries. In terms of getting faster today... we have had great success with is using https://trino.io/docs/current/connector/memory.html. That allows you to create a virtualized result set, an in-memory snapshot of whenever you issued the query that is held in memory on the machine. You can virtualize select * queries or queries for specific columns. This process can be run in a loop to be nearly current (i.e. stale by whatever the execution time is). Then you can point your queries at this result set for best performance.