FOfock·Aug 10, 2026
And this is, when it doesn't delete data randomly: https://github.com/trinodb/trino/issues/28885 (some enterprise open source was slop before AI even it seems)
In How We Pushed CDC into Postgrestrinodb
trino
Java2019–2026
trinodb / trino
trino
Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)
9Distinct people
14Mentions
0Explicit recommenders
13.5KGitHub stars
What to know before exploring
What it is
Official repository of Trino, the distributed SQL query engine for big data, formerly known as PrestoSQL (https://trino.io)
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 5:04:57 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year14 dated mentions
Observed mentions: 2019-01-23 17:51:08 UTC to 2026-08-10 03:39:01 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 1 | 3 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 2 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
14 sourcesTrino: A fast distributed SQL query engine for big data analytics
1 points · Open discussionTrino: Fast distributed SQL query engine for big data analytics
1 points · Open discussionThis is the initial PR which implemented support for this - https://github.com/trinodb/trino/pull/6550
In SQL:2023 has been releasedAlso, you can keep track of all the BQ progress here: https://github.com/trinodb/trino/issues/6867
In The SQL query engine Trino (formerly PrestoSQL) recaps a decade of innovationBigQuery very recently announced their Storage Write API which is one of the ways we were looking to implement this but there are some issues with the latency and consistency guarantees that it offers.
But, yes, we do plan to add that eventually after ironing out all the kinks. See https://github.com/trinodb/trino/pull/13094
In The SQL query engine Trino (formerly PrestoSQL) recaps a decade of innovationCheck out this PR. I believe we may have tackled this one but you'd need to try it out on Trino: https://github.com/trinodb/trino/pull/1415
In The SQL query engine Trino (formerly PrestoSQL) recaps a decade of innovationThe New Fault-Tolerant Execution Architecture of Trinodb
4 points · Open discussionHey I'm a contributor to prestosql (the one that renamed to Trino). I'll provide a few of my opinions into some of these from the vantage point of our project.
* It's definitely confusing but pretty common in open source projects to see the original creators split off when corporate oversight interferes with the OS governance model. (https://www.computerworld.com/article/2746627/hudson-devs-vo...). This is especially true when, as the OP mentioned, it's a pretty cool tech and a lot of interest in it. Now that the names are different, it is clearing up a bit. We're hoping in a few years there will be one project standing so that you won't have to choose. I don't have to tell you which one I think it is.
* Active-active HA is not really necessary IMO as Trino is designed for low latency interactive queries in general. It can handle longer r
Read the rest
unning batch queries but it gives up fault tolerance to fail fast and you just resubmit the query vs predecessors like Hive, Spark, etc... that handle ETL and long running batch processes efficiently but this adds complexity to the query to checkpoint the work. I could see the need for an active-passive HA to have on deck during a failure. Setting up your own active-passive HA is as simple as putting two coordinators behind a proxy and pointing your workers to the proxy address. Then you basically have the proxy run health checks and flip over in the event of an outage. Here's the issue to track native HA though https://github.com/trinodb/trino/issues/391.
* I'm not sure why autoscaling is said to be difficult. I think this is why you have kubernetes and docker to manage this type of workload.
* The only reason this is a pain to me is that engineers wanting to join our community and commit have a bit of a learning curve and depends heavily on us mentoring and guiding them on how the REST API works, which we don't mind. However, I agree with this choice from a design perspective for the user. If you want to use Trino, it's better not to be exposed to this implementation detail or mess with how this works. It will likely cause you more pain.
* This has improved in the last two years since we branched from PrestoDB 2019 (https://trino.io/blog/2020/01/01/2019-summary.html) and 2020 (https://trino.io/blog/2021/01/08/2020-review.html).
* Agreed, we are working on what's the better model here: https://github.com/trinodb/trino/discussions/6573
One quick detail on the Trino description is that not only are some of the initial developers but all of the creators and the majority of contributors (https://github.com/prestodb/presto/graphs/contributors?from=...) and still have contributed the majority of the code in both Presto (https://github.com/prestodb/presto/graphs/contributors)/Trin... (https://github.com/trinodb/trino/graphs/contributors).
To really jump into this, take a look at https://trino.io/blog/2020/12/27/announcing-trino.html.
A few more stats and info:
Trino commits: 22,383
Presto commits: 18,582
Trino slack members: 3,603
Presto slack members: 1,575
Trino supports iceberg: https://trino.io/docs/current/connector/iceberg.html
HDP3 Support: https://github.com/trinodb/trino/issues/1218
Trino has addressed a critical security vulnerability that still exists in Presto: ht
Read the rest
tps://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-1508...
Give our repo a star if you have a sec:
https://github.com/trinodb/trino/blob/master/.github/star.pn...
Disclosure: I work at AWS on infrastructure services
I am personally currently unaware of any AGPLv3 licensed software in use in an AWS service. That said, I would be skeptical of advice to use AGPLv3 due to any particular organization's current policy on the license.
Regarding Presto, work on the service includes changes that should go upstream. For the changes that are appropriate for upstream (e.g., ones that are generally useful, not only of benefit or interest to AWS), PRs are sent. For example: https://github.com/prestosql/presto/pulls?q=is%3Apr+author%3...
Practically speaking, it is difficult to maintain a development branch of any software project with sufficient change velocity if you have a goal of continuing to integrate improvements from the upstream version.
In An update to the Timescale licenseI see such issues on larger multi-module projects. A very reproducable example would be something like Presto (https://github.com/prestosql/presto) or Debezium (https://github.com/debezium/debezium).
I've increasing the JVM heap as much as I reasonably could but giving 2GB of Heap to an IDE on a 16GB system seems wasteful.
In Ask HN: What's the worst piece of software you use everyday?The new repository is https://github.com/prestosql/presto
In Presto-Distributed SQL query engine for big data