Contributor meetings - trinodb/trino GitHub Wiki
The Trino project organizes regular meetings with contributors to improve collaboration with maintainers and among contributors. This space acts is used to plan upcoming meetings and provide meeting minutes after the event.
General information
- Trino Contributor Congregations are in-person meetings, typically run the day after Trino Fest or Trino Summit.
- Trino Contributor Calls are virtual events, typically scheduled for every fourth Wednesday of the month
- Anyone can attend.
- Attendees can request invites from the Manfred Moser on slack
- Attendees can also just join on the day, connections details are announced just prior to the event on slack or on this page.
- Event dates are announced on slack, LinkedIn, and added to the Trino events calendar.
- Topics can be suggested prior to the event by updating this page, pinging a maintainer with the topic on slack, or during the meeting.
- 📹 Video recordings are posted on the dedicated YouTube playlist starting with the April 2024 call.
- Meeting notes and other details are captured on this page.
- Support mosabua for hosting, video recording and editing, and notes at https://github.com/sponsors/mosabua
- Minutes for 2026 call following
- See also https://github.com/trinodb/trino/wiki/Contributor-meetings-2024 and https://github.com/trinodb/trino/wiki/Contributor-meetings-2025
Trino contributor call 2026-10-28
📹 Video recording on YouTube with timestamps
Attendees
- Manfred Moser (mosabua, host and organizer)
- Erik Anderson (dprophet)
- Kent Murra (kmurra)
- Jan Waś (nineinchnick)
- Omer Raifler (OmerRaifler)
- Tony Baeg (tbaeg)
Topics
00:00 Welcome and Trino 484
Trino 484 was released on October 15 and contains all changes since July. Well over 500 pull requests were merged, so many that the pull request description for the release notes could not hold all the links. A lot of the work was co-developed with AI coding tools. The release includes breaking changes, many of them correctness fixes, security improvements, further web UI improvements ahead of removing the legacy web UI, updates to the CLI and Docker container, removal of the PowerPC build, and many connector changes, especially for the lakehouse connectors like Iceberg and Hive. Read the release notes before upgrading and report how it goes.
01:59 Trino Gateway 22
Trino Gateway 22 ships multiple authentication methods, much improved OAuth authentication, tags for clusters that can be used in routing rules, database connection pooling, and UI changes such as a login page. Many changes are already queued up for Trino Gateway 23.
02:50 Trino Grafana data source plugin 1.4.1
Jan reported that the Trino Grafana data source plugin jumped from 1.2 to 1.4.1. The intermediate versions did not pass the Grafana review that is required before a plugin is listed in the Grafana catalog. After applying all requested changes, the plugin passed the review and is available in the catalog, secure, and feature complete. The reviews are anonymous. The last review went quickly, so future releases should be on a regular cadence. Two more pull requests are queued for the next version.
04:31 Git connector 1.0
Jan released version 1.0 of the Git connector. It is the first connector he wrote to learn the Trino SPI, and he recommends writing a connector as an entry point into Trino development. The connector is experimental, since querying a git repository with SQL needs particular use cases, but it is a good exercise to practice SQL and learn the git data model. For 1.0 he applied all conventions from the Trino codebase so it is ready to contribute upstream, which also makes it easier to maintain, and fixed the issues found along the way. He does not think experimental connectors like this should be part of Trino because of the maintenance cost for every release. Manfred asked how the connector works in a distributed cluster. Every worker that a query is distributed to clones the repository as a shallow clone and fetches only what the query needs. Some queries push down specific commits. Concurrent queries do not clobber the local working copy, so the connector is safe to install in a cluster used for other things. Jan noted that accounting for Trino as a distributed system is half the fun of writing connectors.
09:03 Connectors and clients on the ecosystem pages, and Tabularis
Manfred would like more maintainers and all connectors in an official codebase, not necessarily in core, so they are easier to find. Both of Jan's connectors are already on the ecosystem pages. Everyone who maintains a connector outside the official codebase should add it there and follow Jan's example of keeping it up to date with Trino releases, since the SPI changes and a connector must match the Trino release in use. A new client application, Tabularis, supports Trino with a plugin and runs on macOS, Windows, and Linux.
11:04 New Trino user testimonial from Wordfully
Wordfully joined the users page. Their ML team uses Trino to power Wordfully Ray 2.0 and for benchmarks with Parquet files on Amazon S3, a very common Trino use case.
11:50 Trino OpenAPI connector 2.2
Jan released Trino OpenAPI
2.2. The
name confuses people with OpenAI, but the connector is configured by writing an
OpenAPI spec. An existing spec from the API usually needs custom extensions so
the connector knows about pagination and how path parameters map to fields in
responses, which allows predicate pushdown on those fields. The connector is
an experiment in mapping HTTP JSON APIs with path and query parameters to SQL
schemas, tables, columns, and data types, and in hiding API complexities such
as endpoints that only filter on a few fields. It is ambitious and has caveats,
and HTTP APIs are not suited for large amounts of data, but it fits the
federation use case of Trino. Jan is testing it with the GitHub API as a
modern replacement for the handcrafted GitHub connector that powers the
trinodb/reports repository, which
collects data about the Trino repository, its CI jobs, and pull requests. The
connector caches all requests, has a set of pushdowns, and honors API rate
limits, which matters for the aggressive GitHub limits. Version 2.2 is the
result of clearing the whole issue backlog on one Saturday. Multiple catalogs
with different OpenAPI endpoints can be combined in one query, and the main use
case is moving data from APIs into Trino with INSERT INTO ... SELECT without
third party clients.
20:06 trino-go-client 1.4 and feature parity with the JDBC driver
Jan was a guest on Trino Community Broadcast 79 to talk about trino-go-client 1.0.0, and the client is already at 1.4, with 14 new pull requests opened the day before the call. The client reached feature parity with the JDBC driver, which is the reference implementation, including all authentication methods, the direct and the spooling protocol, the latest protocol changes from Trino 484, and the interactive OAuth mode that opens a browser to log in. It is used in the Grafana plugin, and the version numbers of the two projects coincidentally match. Jan noted that most of these features were added for parity rather than on community request, so it is unclear if anyone uses them.
22:00 A feature list for client implementations
Manfred asked whether a master list of client features could be shared, since it would help the JavaScript client, the Python client, and Erik's ODBC driver, and help with test cases. Erik used the Go client as the reference to find what was missing in the ODBC driver, which keeps delaying his big pull request, and he also plans to push out a .NET driver eventually. Jan advised to prioritize the core features needed for day-to-day use over exotic enterprise features like Kerberos, which has good library support in Go but is far away in the JavaScript world. Which features matter depends on the client. OAuth interactive mode is a requirement for a JavaScript client used in interactive applications like the query UI, but not for the Go client that runs in unsupervised backend services. The spooling protocol for large result sets matters less for a UI that only presents aggregates.
26:30 State of trino-js-client and trino-query-ui
Manfred summarized the JavaScript work. The trino-js-client is not used directly in Trino, but in a number of open source and commercial web applications. The trino-query-ui React component is a full SQL editor that currently does not use the JS client. The next steps are to use the client in the query UI to avoid duplicated code, and then to embed the query UI in the Trino preview web UI so users can run queries from the browser. Working prototypes exist, but authentication needs to be sorted out, since it can be handled by the preview UI, the React component, or the client. The query UI should later also run in Trino Gateway, where a query may be routed to different clusters. Upstream pull requests go to tools like the SQL formatter to support the Trino SQL dialect. Help with pull requests and testing is welcome.
28:59 Workload identities for Trino and the clients
Erik raised that client credentials are dangerous and regulatory bodies mandate moving to IAM identities. Their Kubernetes clusters run SPIFFE and SPIRE identities and IAM policies, so IAM identities need to be supported in Trino and passed through and verified by clients like the Go client, across AWS and GCP. Workload identities also isolate whether a human or an AI workload is accessing Trino, since Trino was never designed for AI access to billions of data sources. A client is needed as the place to start before rolling it out to the JDBC driver and the other clients. Kent wants to discuss this offline, since his team has the same goal of letting AI use Trino safely. Permissions for AI should derive from the user with extra restrictions based on where the bot runs and what it connects to, for example a Slack bot that must never return PII. Their team is looking at extending the identity object in the authentication layer in a custom plugin, which the current authentication and authorization model does not support well. Erik added that Bloomberg heavily forked the identity model and needs to move back to industry standards, since maintaining forks is costly, and that he is working on wireframes for a project called Trinoculars for authorization with IAM identities and AI agents. People increasingly have Claude create dashboards instead of using dashboarding tools, and Kent's company is dropping one of its Tableau and Mode subscriptions, which is one more reason to have good clients. Manfred noted that the CLI and the JDBC driver in the core codebase have been the leading implementations, and that a feature in another client eventually has to flow back into core without breaking shipped clients. Jan pointed out that the Go client allows replacing the complete HTTP client, so a custom authentication method can be plugged in. He is the only reviewer for the Go client and might not know all the conventions of the JDBC driver, so he recommends starting the discussion with a pull request for the JDBC driver in the Trino repository, where more maintainers give feedback. He is open to pull requests for the Go client and strongly in favor of workload identities over stored credentials.
38:02 MCP servers for Trino
Manfred mentioned the earlier discussion about an official MCP server for Trino. The AI functions in Trino are a small step, and various community MCP servers exist, some of them impressive, including ones that manage clusters. Official MCP servers in the Trino project would be nice, but there is no bandwidth. Some people just use the CLI with skills, but the advantage of MCP is that the AI agent never gets access to the credentials. Erik uses subagents that must not read environment variables and only load secrets from a dedicated directory.
40:09 Iceberg branching pull requests
Kent asked again for reviews of Stefan's Iceberg branching pull requests, Use table schema when reading Iceberg branches and Add branch management to Iceberg connector. They have been ready for review for three weeks without traction. Branching is a very high priority, because it is currently the only way to update an Iceberg table atomically. Toolkits for slowly changing dimension tables delete a time period and then write it, and a dataset built from the table during the delete sees incorrect data. Transactions for Iceberg were discussed earlier and not wanted, so branching is the other way. Manfred will follow up with the links in the notes and ping reviewers. Reviews are slower than everyone wants.
42:02 Serialized Iceberg table commits
Tony has a related pull request, Add option to serialize Iceberg table commits. Many concurrent queries collide in the compare-and-swap commit and cause retry storms with massive latency. Serializing the commits gives higher throughput and may help with Kent's problem in a roundabout way. Tony needs reviews and is patient, given how much is going on.
43:19 Table-local staging directory for the Hive connector
Omer asked for input on Add opt-in table-local staging for Hive inserts and
CTAS. The staging directory in
the Hive connector is a global path, and their file system cannot move
directories between what it calls qual domains, which prevents using the
staging directory and therefore ACID-like behavior for writes. The proposal
makes the staging directory a subdirectory of the table directory, the same way
Spark and Hive do it. It sounded simple, but operations like CREATE TABLE AS
rely on the global staging directory, so the change alters the commit protocol
for some operations. Omer opened a draft pull request, developed with Codex,
and asked whether such a change would be accepted. Manfred cannot speak for
the Hive connector internals and suggested a sanity check by maintainers who
know it, such as David. Omer had already discussed the initial proposal with
David, who found it reasonable before the extra complexity surfaced. Manfred
suggested posting a general call in the #core-dev channel on Trino Slack and
looking at the commit history of the Hive connector for other maintainers.
48:22 Wrap up
The next call is planned for 2026-11-25, just before US Thanksgiving. Details are on the Trino community events page.
Trino contributor call 2026-09-30
📹 Video recording on YouTube with timestamps
Attendees
- Manfred Moser (mosabua, host and organizer)
- Dain Sundstrom (dain)
- Erik Anderson (dprophet)
- Kent Murra (kmurra)
- Peter Kosztolanyi (koszti)
- Jan Waś (nineinchnick)
- Roey Ogen (RoeyoOgen)
- Ben Breakstone (bbreak)
- Tony Baeg (tbaeg)
- Darin Chandler
Topics
00:00 Welcome and trino-js-client 1.0.0
The JavaScript client is now published in the @trinodb scope as
@trinodb/trino-js-client
1.0.0. The
JavaScript components now use major versions only, just like Trino, and leave
the decision about breaking changes to the consumer. The release documents which
projects use the client, adds tests, and declares Node 24 as the tested version.
It builds on the modernization in the 0.3.x releases from a month ago. Next
steps include removing Axios, adding Trino data types, and exporting header
names, in preparation for use in trino-query-ui.
02:32 trino-query-ui 1.0.0 and 2.0.0
@trinodb/trino-query-ui 1.0.0 aligned the dependencies with Trino, fixed the Monaco worker, and got npm publishing working with the new registry and GitHub organization configuration. 2.0.0 adds UI changes and cleanups, and ships the TypeScript declarations to simplify embedding the component in the Trino web UI and elsewhere. The query UI still embeds its own minimal client, and the plan is to replace it with trino-js-client.
04:10 Trino Grafana data source plugin 1.2.0
Trino Grafana data source plugin 1.2.0 adds support for private data source connect, which makes the plugin suitable for production use in Grafana Cloud. It follows the recent 1.1.0 and 1.1.1 releases.
04:59 trino-go-client releases
The Go client is currently the most active client project, with a series of releases up to v0.337.0. Much of the work comes from Sylwester Lachiewicz (slachiewicz), also known from the Maven community. The client is now close to the JDBC driver in features and quality and performs very well.
05:55 trino-python-client 0.340.0
trino-python-client 0.340.0 was cut by Mateusz Gajewski (wendigo) and includes a number of fixes and improvements, and an option to opt out of insecure connections.
07:07 Authenticated statement endpoint for the web UI
Peter presented PR #31023, which
adds a web UI endpoint for running queries. The query UI cannot use the
/v1/statement endpoint for good reasons around authentication. The PR exposes
the needed parts of the statement protocol under the web UI path, where the UI
is authenticated. It is a blocker for embedding the query UI in Trino, and the
same approach helps when running the query UI in Trino Gateway. Dain noted that
this is a useful first step, and that the endpoint can later evolve
independently of the client protocol, since it only needs to match the web UI
that ships with it. Reviews are welcome.
11:07 New Trino user testimonials
The Trino users page now includes testimonials from Blinkit, a large e-commerce platform in India, Datadog, which uses Trino internally, offers a Trino integration, and contributes Iceberg improvements, and OpenAI, which runs a massive interactive data lake on Trino for agents and people. The OpenAI testimonial comes from Eric Hwang, one of the original creators of Presto at Facebook.
12:52 PostgreSQL support in the DB session property manager
Roey presented PR #31015 for issue #31013. The database backed session property manager exists but was undocumented and only supports MySQL. The PR adds the same factory approach used by the database resource group manager, so PostgreSQL and other databases work as well. Combined with resource group selectors, session properties can cap memory and CPU for queries at runtime, not just at admission. Erik's team built a similar PostgreSQL backed manager internally but never open sourced it, because users can override session properties in their queries. Options include setting properties in Trino Gateway with an external routing service, blocking changes with the system access control, or a future extension that enforces properties over user values. Erik noted that users can bypass Trino Gateway and connect to the coordinators directly, so enforcement belongs in Trino itself, while Roey noted that this depends on whether only the gateway endpoint is exposed. Roey is happy to extend the PR and is following up on the core-dev channel.
18:47 Iceberg branch management pull requests
Kent is looking for guidance on getting Iceberg branching support merged, which is a high priority for his team. The current work from stefan-toubia consists of PR #30977, which uses the table schema when reading branches as required by the Iceberg specification, and the stacked PR #31135, which adds branch management. Both need conflicts resolved, fixup commits squashed, and commit messages fixed with a title of at most 50 characters and a body wrapped at 72 characters. The smaller PR #30977 should go in first. Yuya is the maintainer familiar with the area, so Kent pings him directly, and Manfred follows up on the maintainers channel. The consensus is to give the original author time to finish the work rather than re-implementing it.
26:00 Next Trino release and a release notes skill
Trino 483 shipped two months ago and no release notes pull request for the next release exists yet. Erik is waiting on the new custom secrets provider interface, documented in PR #30692 and not yet in a release. Manfred asks the maintainers about release plans. He uses an AI skill from his getting-stuff-done repository to create and update the Trino Gateway release notes pull request, and plans to try a version for Trino. Dain would like to see releases further automated, which is now achievable with enough attention.
29:22 Test infrastructure and merge queue
The merge queue and the new product test infrastructure make CI much more reliable and faster. The remaining failures mostly come from overloaded external services such as Databricks and Snowflake.
30:13 ODBC driver testing and AI for driver testing
Erik reports that merging the Trino ODBC driver is delayed by automated testing, with full test coverage and CI setup for OAuth 2.0 tokens still missing. Dain recommends letting AI build a test suite that compares results from several other drivers against the same queries and tables, since drivers with reference implementations are well suited for this approach.
33:07 Go client feature parity and Grafana plugin releases
A detailed comparison of the Go client with the JDBC driver as reference implementation showed a bigger gap than expected, and work towards feature parity is ongoing. The refactored test suite is about ten times faster. The Go client includes a full spooling protocol implementation that can be used directly for high throughput reading, beyond what the JDBC driver offers. Jan plans to cut version 1 once parity is reached. For the Grafana plugin, the new end-to-end tests across Grafana versions enable regular releases. Each release goes through a manual review by Grafana with strict dependency and security checks, which takes from two days to two weeks.
37:29 OpenTelemetry logging and real histograms in Airlift
Dain merged native OpenTelemetry log export into Airlift with PR #2037, including capture of all startup messages. It is not yet tested in production. He also added OpenMetrics exponential histogram support with PR #2047, using a minimal manual protobuf exporter. This allows Trino to collect histograms instead of a more expensive data structure and improves integration with observability platforms. Both changes ship in a future Trino release.
39:16 Regulator regular expression engine
Dain opened PR #31316 to integrate Regulator, a new pure Java regular expression engine. It started as a port of RE2, adds optimizations from many other engines, uses the Java Vector API heavily, and runs about twice as fast as native RE2. It supports RE2 syntax, Java regular expressions, and the Trino regular expression dialect. Dain shared tips on guiding AI with high performance Java work, such as comparing generated assembly and checking cache behavior.
42:10 Feature parity check before removing the legacy web UI
Manfred and Peter plan to use AI to compare the legacy and the new web UI for feature parity. No missing features have been reported, and the goal is to remove the legacy UI in a release or two.
42:59 New classfile library in Airlift
Dain added a new classfile library to Airlift that replaces the bytecode library for code generation and uses the modern Java class file API. It automatically splits large methods, so the "method too large" error goes away. AI-driven scale tests of the Trino compiler establish limits such as the maximum number of group by columns.
43:56 Trino Gateway bug with compressed prepared statements
Manfred mentioned a Trino Gateway bug discussed earlier that day. Trino compresses large prepared statements, and the gateway checked for the compression prefix before decoding the header, so routing failed for those queries. PR #1289 fixes the decode order.
44:27 Debugging query performance with traces
Erik asked about standard approaches for troubleshooting query performance, as more AI agents connect to Trino. Jan clarified that the Grafana plugin is for querying data from Trino, not for monitoring Trino itself. For problematic queries, he recommends per-query data such as traces or an event listener that categorizes query statistics. Dain suggests capturing full traces from repeated runs on a separate cluster with a collector such as the Grafana LGTM stack, and giving them to an AI for analysis, ideally with a similar benchmark dataset to iterate on. Erik's team already open sourced the HTTP event listener and ingests all query events, and has looked at tail sampling. Since full tracing at production scale overwhelms observability systems, a per-query flag to fully trace a query and send it to a dedicated collector would be valuable. Roey suggested using Trino Gateway to route selected queries, for example by query fingerprint, to a production cluster with tracing enabled.
Trino contributor call 2026-08-26
📹 Video recording on YouTube with timestamps
Attendees
- Manfred Moser (mosabua, host and organizer)
- Erik Anderson (dprophet)
- Dain Sundstrom (dain)
- Kent Murra (kmurra)
- Raunaq Morarka (raunaqmorarka)
- Omer Raifler (OmerRaifler)
- Nitesh Yadav (niteshy)
- Oussama Ben Nasr (oucemabennasr)
Topics
00:00 Trino release status after 483
No new Trino release since 483, which shipped just before the previous contributor call and added a large batch of new SQL statements. The call therefore focuses on the wider Trino ecosystem rather than the engine release itself.
00:52 Product test framework on JUnit, faster CI, and the merge queue
Dain and David replaced the TestNG-based product test framework with a new one based on JUnit, and updated essentially every Docker image used by it. Follow-up work reorganized the GitHub Actions jobs, cutting a full CI run from about an hour to roughly 35 minutes by using more of the 500 concurrent jobs available on the enterprise account. See PR #30096 for the initial migration, PR #30557 for the removal of the legacy framework, PR #30846 reducing the product test bundle from 5 GB to 250 MB, and PR #30863 running the suites in parallel. Trino now also uses a merge queue for maintainers, which everyone on the call agrees is hard to give up once you have it.
02:38 Engine performance work in Trino
Raunaq reports that most of the interesting recent engine work comes from Dain, in particular storing boolean arrays in blocks as packed bit maps for a significant efficiency gain. See PR #30299 and PR #30185. Further related pull requests with good expected gains are still under review.
03:32 Iceberg branch management
Kent describes branching support as the feature his team at Remitly is most interested in. He plans to pick up the stalled PR #28464 from SebastienN15, redo it, and credit the original author. The SQL syntax for creating and managing branches already exists in Trino and only needs to be plumbed through to the Iceberg connector. For review support on branching, ebyhr is the maintainer most familiar with the area.
05:12 Trino Grafana data source plugin 1.1.1
The Grafana data source plugin is unblocked again. Jan Waś, with help from an external contributor, got the test suite and the compatibility tests for older and newer Grafana versions working again. v1.1.0 adds row support and client tags, revamps the SDK, and fixes the OAuth handling; v1.1.1 follows up with further changes. More features and improvements are in progress. Note that this plugin lets you visualize Trino data in Grafana, not the other way around.
06:22 Native OpenTelemetry metrics from Airlift
Dain extended Airlift and jmxutils so that Trino natively exports OpenTelemetry metrics, including exponential histograms, in addition to the OpenTelemetry spans it already emitted. This is considerably better than having an OpenTelemetry collector scrape JMX and convert the result. A further pull request that exports logs over OpenTelemetry is still stalled.
08:38 trino-js-client 0.3.1 and restored npm publishing
Publishing of trino-js-client to
the npm registry works again after close to a year of being blocked. The current
release is
v0.3.1,
published under the new @trinodb scope as @trinodb/trino-js-client. A batch
of dependencies was updated, more updates are queued, and removing the Axios
dependency entirely is under consideration.
09:38 trino-query-ui 0.1.5 and a query editor for the web UI
The same publishing fix landed for trino-query-ui, now released as 0.1.5. Manfred and Peter Kosztolanyi are aligning its dependencies with the Trino web UI, after which the query editor component gets added to the new default Trino web UI. The component is standalone, so it can be started locally and pointed at a Trino cluster without waiting for the integration. Thanks go to George Fisher for the original contribution. Help from anyone comfortable with JavaScript is very welcome. One quirk to sort out is that trino-query-ui currently bundles its own JS client instead of using trino-js-client; the two will likely be merged.
11:05 Query UI in Trino Gateway and standardizing on MUI
Adding the query UI to Trino Gateway came up in discussion and is planned. The Trino ecosystem is standardizing on Material UI, and the Trino Gateway UI does not use MUI yet, so it needs to be reworked first.
12:12 Versioning for the JavaScript components
Both JavaScript components currently carry 0.x versions despite being usable. Manfred asks whether moving to the Trino model of a single incrementing number makes sense instead of following the semantic versioning tradition of the JavaScript ecosystem. The consensus is that semantic versioning matters for components other things build on, and these are leaves that only sit on the client protocol and do not advertise Trino compatibility through their version anyway. A switch is likely with one of the next releases.
14:32 Trino Gateway 21 release
Trino Gateway 21 was released the night before the call. It adds LDAP bind without user search (PR #1205), working JWT support with client certificate authentication (PR #1022), and SQL request body fixes. The spooling protocol now works cleanly for most configurations, including deletion of the spooled files on object storage, which previously went stale because some forwarding rules did not pass the requests through. Following Trino, PowerPC container images are no longer built. Changes for Gateway 22 are already lined up, with a release expected end of September or in October.
16:15 Airlift configuration validation and HTTPS-only defaults
Manfred asks about an Airlift update that now fails startup when a configuration property is unknown or unused, which held up the Trino Gateway 21 Helm chart. Dain explains this was a deliberate design change: when HTTP is disabled, the related HTTP options are no longer available, so setting an HTTP port alongside HTTPS breaks startup. The intent is that everyone should use HTTPS everywhere and not see HTTP options printed when they are unused. Manfred takes an action to clean up the affected test case and to check whether the change is called out in the Trino release notes.
18:45 Nested LDAP group resolution in Trino Gateway
Omer Raifler is working on nested LDAP group resolution for Trino Gateway, see PR #1197. It is in code review with Pravin and expected to merge soon.
19:08 How to propose a feature before building it
Omer asks where to socialize a design document before opening a pull request.
The advice is to raise it in the #core-dev channel on Trino
Slack first, and to file an issue when more discussion
is needed so the plan is findable later. Getting agreement on direction before
investing serious time avoids wasted work when an approach turns out not to fit,
and it also gauges whether anyone is willing to review it. Very esoteric
features can end up with no reviewer available at all. Examples discussed
include a query result cache for Trino Gateway, which has a backlog issue but no
implementation, and driver support for AWS load balancer OAuth, where the token
arrives in an Amazon-specific header without the Bearer prefix. A small
configurable option for which header the JWT bearer token is read from is
floated as a possible fix.
25:08 Trino Gateway high availability and split brain
Erik describes wiping out a single-instance Trino Gateway through VM sizing and losing availability for around 90 seconds while a JVM memory dump was written. Running multiple Gateway instances in Kubernetes for resiliency currently causes a split brain. The known problems are keeping the database and the per-instance caches from going stale, and the UI. A related failure mode is losing the backing database, after which the Gateway fails without telemetry that would show what went wrong.
26:38 Constant specialized and columnar scalar functions
Dain walks through two pull requests that make functions faster. PR #30300 adds constant specialized functions, where a constant argument is bound into the function instance so things like regular expressions can be precompiled without engine-specific types, with care taken not to blow up the caches by specializing on every possible constant value. PR #30301 adds columnar scalar functions that operate on whole blocks. Naming is still open, since "scalar" only means not aggregate, window, or table function; "batch", "factorized", or "vector scalar" were suggested. The speedups are substantial for functions that just manipulate blocks, such as unnesting deeply nested fields or array manipulation, in some benchmarks by orders of magnitude. Applying it everywhere is not automatic, because the existing code generation already auto-vectorizes well, so it needs significant benchmarking.
31:35 Benchmarking with AI and a new regular expression engine
Benchmarking is far easier than it used to be, since an AI agent can drive cloud instances and produce results across platforms instead of hand-configuring remote JMH runs. Dain has been building a new regular expression engine since January, benchmarked across two ARM generations and Intel against a large corpus. Trino already uses a fork of Joni with Trino-specific extensions, so it has its own regular expression engine and language; the new one is based on RE2 plus additional algorithms from other engines and is significantly faster.
32:28 Parquet filter pushdown and virtual threads
Two more in-flight changes: PR #30303 pushes filters down into Parquet, a significant win for needle-in-a-haystack queries and neutral otherwise, and PR #30477 switches split execution to virtual threads. The virtual threads change is not a performance win by itself; it makes it possible to rewrite operators in a blocking style instead of the current yield-and-replay gymnastics.
33:40 Large pull requests, the Guice fork, and AI-assisted review
Several of these changes are very large, and landing them is a real problem. The regular expression engine alone is around 50,000 lines. Mateusz has been working on a fork of Guice in Airlift since Google abandoned it, modernizing it and removing ancient dependencies such as old ASM versions with known vulnerabilities, and the first pull request is around 100,000 lines, see airlift PR #2114. Reviewing at this scale increasingly means using AI for the review alongside strong test coverage and benchmarks. Manfred cautions against rewriting too much in-house, with the counterpoint that in these cases the upstream projects are unmaintained and the APIs stay the same. Well-executed rewrites may also attract other users and contributors.
36:40 Java 28 and Project Valhalla
Trino sits on Java 25 and did not upgrade to 26. It will likely skip 27 as well and target Java 28 next year, which is expected to carry the Project Valhalla work and significant performance opportunities with it. Mateusz has already started work towards Java 28.
37:12 Identity propagation and credential exchange for connectors
Erik raises the long-standing need to push the identity Trino receives down into
the storage layer, for Apache Polaris and Iceberg as well as for a
Trino-to-Trino connector, so that quality of service levels on S3 and file
transfers can be set per identity. Knowing a user's identity is not enough,
because entitlements live in the underlying system and each system has its own
token format, so a token exchange is required. The earlier attempt in PR
#29538 was abandoned. Separately,
PR #30125 from gertjanal
implements OAuth2 token exchange to obtain per-user credentials for the AI
functions. Dain's feedback there was that the AI-specific version is too narrow
and the right shape is a generic plugin interface, a credential resolver that
lets any connector exchange the user identity for a token, with a handful of
built-in implementations and room to extend. That covers Polaris, Iceberg REST
catalogs, PostgreSQL, Cassandra, and more. The known cost is that per-user
credentials force per-user data, which effectively disables shared caches, as
already seen in the Hive connector. The agreed next step is to coordinate on
Slack and have the contributor build it with Dain reviewing. Since the call,
gertjanal opened PR #30944, which
introduces a CredentialProviders SPI with OIDC token exchange and basic auth
providers.
44:48 Trino-to-Trino connector
Manfred points out PR #30290 from kkd927, a read-only Trino connector for remote clusters, which appears to be inspired by but separate from the work Erik and Saj have been doing. The umbrella issue #21791 collects the characteristics, the known bottlenecks, and the planned improvements for a Trino-to-Trino connector, and exists to pull the various stakeholders together, so getting something into Trino itself avoids repeated reimplementation. Erik's blocker is the same token exchange discussed earlier, since the current approach needs a superuser role account that can impersonate any user. The other bottleneck is transport: row-by-row transfer is far too slow and something compressed and columnar is needed.
46:35 Apache Arrow for result transfer
Kent suggests Apache Arrow as a transport candidate, noting existing interest in Arrow support at the driver level, as Snowflake does for its JDBC driver, with Flight SQL as another option. AI workloads move large volumes of data, so compressing by column beats the row-level compressed JSON used today.
47:55 Keystore-based S3 credentials in Airlift
Nitesh Yadav asks for direction on PR
#30638 and airlift PR
#2100, which add keystore-based
S3 credentials because the existing Airlift secret provider does not support the
Hadoop key format. Mateusz responded on the Airlift pull request that this is a
legacy format that should not be added upstream. The guidance on the call is
that Airlift's secret provider mechanism is extensible, so this can be shipped
as a plugin without rebuilding anything; it is straightforward to write one that
resolves configuration secrets from AWS Secrets Manager or similar. This applies
to static credentials bound into configuration at startup, not to live per-user
credential exchange, which is the separate and harder problem discussed earlier.
Nitesh will follow up in the #core-dev Slack channel with Dain, David, and
Mateusz.
51:55 Updating the Hadoop dependency
A question about updating the Hadoop dependency to 3.3.6 is directed to the
#core-dev Slack channel. Dependency updates are generally welcome, and the
only remaining real Hadoop dependency is HDFS, since everything else has been
replaced with Trino's own code. Hadoop is still used in tests, where being fully
up to date matters less.
Trino contributor call 2026-07-22
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer), raunaqmorarka, OmerRaifler,
Topics
00:00 Trino 483 release and SQL improvements
Manfred and Raunaq review the recent release cadence and the SQL work in Trino 482 and 483. The Summer of Grammar post covers the Trino 482 grammar additions and the new trysql.io sandbox. Trino 483 adds further SQL features, including PIVOT, JSON dot notation, and three-dimensional geometry support. See the Trino 483 release notes for the complete release details and the A pivotal summer blog post for demos
04:06 New Trino web UI becomes the default
The former preview UI is now the default web UI. The legacy UI remains available temporarily, but will be removed in a future release. Contributors are asked to report missing features or contribute them to the new UI. Query editing is planned as a follow-up improvement.
05:45 Production memory fixes
Raunaq describes production heap-dump analysis that identified two memory problems. PR #30372 reduces the Parquet writer's footprint for dictionary-encoded columns. PR #30321 prevents large dynamic filter predicates from filling the compiler cache with generated classes.
09:02 Anonymous S3 access
PR #27758 adds the
s3.auth-type=ANONYMOUS option for public S3 buckets. It lets users access
public data such as ClickBench and NYC Taxi datasets without configuring
credentials, and removes ClickBench's need to rely on the older HDFS
filesystem path.
11:20 CLI themes and Trino packages
The CLI now supports output color themes. Manfred also notes that trino-packages has been updated for Trino 483, enabling users to build custom container images and tarballs from the latest release.
12:41 Trino Gateway 21 and the spooled client protocol
The next Trino Gateway release is expected the following week. The spooled client protocol now works with Trino Gateway, including deletion of the object-storage files used for spooled results. The team requests help reviewing and testing the remaining Gateway changes.
13:54 Client releases and build improvements
The group notes a recent Python client release and continuing work on the JavaScript components. Raunaq summarizes build-time improvements from updating Provisio and switching package generation to streaming with compression. Manfred explains that the Trino Maven plugin creates plugin ZIP archives with each plugin's dependencies, and plans to apply the same Provisio improvement to trino-packages.
17:20 Community call to action
The next contributor call is planned for the end of August. Contributors are encouraged to help review pull requests, test changes with their workloads and data, and share their experience on Slack.
Trino contributor call 2026-06-24
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer), dprophet, pettyjamesm, wendigo bbreak)
Topics
00:00 Intro, Trino query UI, and JavaScript client publishing
Maanfred Moser introduces the call. The team discusses the upcoming release of the Trino query UI and the Trino JavaScript client to the trinodb namespace on the npm registry. They also discuss switching the default UI to the new one and deprecating the classic UI in a few releases. (Note: The unrecorded first part of the call also touched on Issue #30020 regarding handling the Oracle Geometry type in Trino, and Issue #20807 to restrict column dropping operations on Hive tables).
00:48 Autoscaling, KEDA, and Resource-aware admission control
The team discusses scaling patterns for Trino. James (pettyjamesm) explains their use case where they run up to 70 concurrent queries per cluster and route ETL writes to dedicated write clusters. They discuss Kubernetes scaling using KEDA (https://keda.sh/), which was suggested by dprophet. They also review PR #29944 (Resource-aware query admission control based on memory/vCPU) by skagraw16. James notes that since Trino does not autoscale existing running queries when new nodes are added, it is essential for admission control to hold the query in WAITING_FOR_RESOURCES until resources are available.
08:24 Trino Maven plugin rewrite
Matteo discusses progress on the rewrite of the Trino Maven plugin to eliminate the Proviso dependency for plugin assemblies, replacing it with the default Maven assembly plugin. Proviso will still be used for server packaging.
09:12 TPC-DS Test Suite spec v4 updates
Manfred and Mateusz discusses updating the TPC-DS test suite data to version 4 of the specification, which involved regenerating statistics, plans, and missing queries. The team plans to run benchmarks to establish a new performance baseline.
10:26 Trino Statement Utils compatibility in Trino Gateway
The team discusses a bug in Trino Gateway where drift in the StatementUtils class caused routing failures for new keywords like SHOW BRANCHES. The class has been updated, and an integration test was added to verify compatibility and break the build if they drift again during Trino updates.
11:21 New Trino online sandbox: trysql.io
Wendigo introduces Martin's new Trino sandbox at trysql.io (https://trysql.io/). It allows you to test queries on a live running Trino instance without running it yourself. It is used in the blog post about new SQL grammar supports.
Trino contributor call 2026-05-27
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer), dain, dprophet, pettyjamesm, raunaqmorarka, RoeyoOgen
Topics
00:00 Trino 481 release
Discussion of the latest Trino 481 release highlights, including key features and improvements.
00:30 trino-packages updated to 481
Update on the trino-packages repository which has been aligned with the 481 release.
01:15 Trino Gateway 19/20 status
Trino Gateway version 19 is out, and version 20 is expected in June. The skill to maintain release notes is confirmed to be working.
02:45 C# client build PR
Call for help with the .NET/C# client build process, specifically on PR #34.
03:50 JS client and query UI npm flow
Seeking reviews and input for the npm registry publishing workflow for the JavaScript client (PR #953) and the query UI (PR #35).
05:10 Web UI switch for Trino 482
Plans to merge the new web UI (PR #29285) soon, likely before the upcoming 482 release.
06:20 Trino Community Broadcast guest call
Call for guests for upcoming episodes of the Trino Community Broadcast. Reach out to Manfred if you have a topic to share!
07:45 Geospatial functionality and Iceberg V3
Discussion on geospatial functionality, Iceberg V3 support, and handling of geometry types, linked to PR #27893.
09:15 New language features (SQL/JSON, Named args, CASE, PIVOT)
Request for review of several PRs from Martin for new language features:
- PR #29565: SQL/JSON simplified accessor.
- PR #29530: Named arguments for ordinary function calls.
- PR #29446: Support for extended CASE expressions.
- PR #29404: Support for PIVOT.
11:30 Connector Updates (Teradata, Hudi)
Status updates for the Teradata connector (no recent progress) and the Hudi connector (ongoing refactoring into an external library).
Trino Contributor Call 2026-04-29
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer) dain wendigo dprophet Pratik Deshpande, Agnes Tevesz
Topics
0:00 Intro and ODBC driver progress
Discussion on the strategic roadmap for the Trino ODBC driver, specifically focusing on enabling robust read-only access for Microsoft Excel and PowerBI on Windows. The goal is to move beyond specific utility toward a feature-complete driver. Also discussed PR strategy.
03:38 Metadata queries for filtering tables in a UI
The team discussed implementing schema and table metadata caching for lists of catalogs, schemas, and tables in a UI and for filtering. This is designed to improve performance when BI tools or UIs request metadata frequently. Also applicable to the trino-query-ui, Trino and Trino Gateway.
24:05 aws-proxy
Discussion of the aws-proxy subproject, which assists with use cases
involving AWS S3, metastores, and other storage systems. Plans for continued maintainer help and
progress with merges.
26:00 Azure request limit
Review of rejection signals and handling for custom gateways when hitting Azure-specific API or request limits. Help for contributing to Trino.
28:05 OAuth token exchange and trino2trino connector
Technical talk on implementing a generic "credential broker" flow for OAuth token exchange related cross-cloud authentication scenarios and the trino2trino connector.
32:45 Airlift compression PR
Wendigo will reach out to the Jetty team for further feedback on Airlift integration. Related to PR https://github.com/airlift/airlift/pull/1660 and need in Trino Gateway.
38:20 Internal cluster traffic on different HTTP ports
Discussion on separating internal cluster traffic from external requests using different HTTP ports for improved security and routing.
44:00 Trino release automation
Discussion on automating Trino releases and developing a skill to generate structured release notes for the community. mosabua to test with Trino Gateway.
51:15 Native zstandard input and output streams
Dain and the team analyzed performance regressions and the implementation of native Zstandard streams for high-throughput data transfers.
Trino Contributor Call, 25 Mar 2026
📹 Video recording on YouTube with timestamps
Attendees
mosabua, wendigo, dprophet,xkrogen, sc250072
Topics
0:00 Trino 480 release
The team walked through the highlights of the Trino 480 release, most notably the integration of Iceberg 3. A significant housekeeping note was the removal of the Vertica connector. On the infrastructure side, the project is officially staying with Java 25 for the foreseeable future; Java 26 is not being adopted at this stage
5:12 Trino Gateway 18
The discussion moved to the latest updates for Trino Gateway 18.
8:45 Teradata connector PR progress
A deep dive into the Teradata connector revealed some ongoing friction. The contributors discussed specific technical obstacles preventing a smooth merge, alongside a broader conversation about community health. There is a concerted effort to ensure that new connectors have enough long-term maintainer interest to avoid the "abandonware" issues seen with older, now-removed connectors.
15:20 Other topics
The call wrapped up with miscellaneous community update. The contributors emphasized the importance of staying active on the Slack channels to help triage smaller PRs that often get lost in the shuffle.
Trino Contributor Call, 24 Feb 2026
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer), dprophet, wendigo, RoeyoOgen,
Topics
[00:13] New maintainer - Chen Jian (Jack) The meeting began with congratulations to Chen Jian (known as chenjian2664 or Jack on Slack), who has officially become a Trino maintainer. Jack has been recognized for his high-quality reviews and consistent contributions over the past year.
[00:44] Trino Gateway 17 and upcoming 18 The release process for Trino Gateway 17 is now fully automated via GitHub Actions, including container publishing to Docker Hub. The team is moving back to a monthly release cadence, with Version 18 expected to be cut next week.
[01:57] Trino 480 and blocker Development for Trino 480 is ongoing, but it is currently facing a release blocker related to the Delta Lake connector. The team is working to resolve this before shipping the release.
[02:15] Trino packages progress The Trino packages repository is currently falling behind schedule and requires manual updates. This repository is used for creating custom tar, Docker, and RPM packages; the community is encouraged to submit PRs to help maintain it.
[02:41] C# client looking for help There is a call for help with the Trino C# client. While the community is sending PRs, there is a lack of maintainers with .NET expertise to manage the release workflow and trusted publishing to NuGet.
[04:49] JS UI and client publish issue The JavaScript UI and client are facing publishing issues related to "trusted publishing." Setup is required to properly sync GitHub with the npm registry to automate these releases.
[05:11] Plans to switch Trino default UI to preview The team plans to switch the default Trino UI to the "Preview" version after the 480 release, as it has reached feature parity. The legacy UI will be renamed to "Classic" and will be phased out over several releases. Future plans include adding a query editor directly into the web UI.
[08:18] Iceberg effort - Iceberg V3 Support Dain and others have put significant work into Iceberg V3 support, including features like geometry types and coordinate conversions (e.g., PR #27893). However, these PRs are currently "stuck" due to a lack of community reviews.
[11:23] Grafana PR and contributors The Grafana Trino data source plugin needs more reviewers. Maintainer Jan is currently overwhelmed with multiple projects (including Helm charts and the Faker connector). Since the plugin uses Go and JavaScript, contributors with those skills are encouraged to help with PRs like #317.
[18:33] OAuth repo move Erik discussed the status of OAuth 2.0 PRs for the JDBC and Python clients. He specifically needs coordination with Martin, Dain, or David to handle repository creation and permissions for these library moves.
[23:34] OPA tooling repo The new trino-opa-tools repository has been created to host OPA and Ranger connectivity tools. Erik and Pablo are expected to have access to push code there. If any issues arise, Manfred (mosabua) is the point of contact.
Additional Technical Notes:
[20:59] Internal HTTP/2 has been re-enabled for clusters. It has proven stable in production and is expected to be included in Trino 480 to improve cluster communication and reduce GC pressure.
Trino Contributor Call, 28 Jan 2026
📹 Video recording on YouTube with timestamps
Attendees
mosabua (Host and organizer), dprophet, kbhatianr, Satish Chintahippu (@sc250072), Doug Balog, Akintoye Olorode, Harishankar Mishra, Lalit Murmu
Topics
00:00:02, Introduction and Housekeeping
The meeting opens with a brief welcome and an overview of the agenda for the day, focusing on connector updates and client improvements.
00:01:15, Teradata Connector Review
The team discussed the progress of the Teradata connector (PR #26731). There is a request for a final round of reviews from Piotr and David to move toward merging. Mosabua to ask for review
00:04:45, PowerBI Connector & Microsoft Collaboration
Discussions regarding the native PowerBI connector. Manfred is set to follow up with Microsoft and other stakeholders to improve the integration experience for PowerBI users.
00:08:30, ODBC Driver Status & Client Improvement Project
A deep dive into the Trino client improvement project, specifically targeting machine-to-machine communication. This includes OAuth2 support for the Python client (PR #589) and the Java implementation.
Also asking for migration of the projects
https://github.com/dprophet/trino-python-oauth2
and
https://github.com/dprophet/trino-java-oauth2
into the trinodb org. Manfred to ask
00:15:20, Iceberg Migration Challenges
Doug shared experiences regarding Iceberg table migrations. He noted that while Spark is the primary tool used, the process has been problematic and didn't really work as intended in recent trials.
00:22:10, Table Functions PR Review
A request for input and additional review for the Table Function PR (PR #27696). Mosabua to ping maintainers.
00:28:50, LanceDB Connector Comparison
Discussion on the two different LanceDB connectors (lance-trino vs PR #26987). The team referenced technical details previously discussed during Trino Fest 2024 - also see the video
00:36:15, Conclusion and Q&A
Wrap-up of the meeting and final comments from the maintainers.