{"slug": "substrait", "name": "Substrait", "category": "dev-libs", "category_name": "Libraries and frameworks", "description": "", "recommenders": 6, "commenters": 6, "warners": 0, "score": 5.432, "rising": 0.69, "first": "2026-02-06", "latest": "2026-09-12", "why": "I hope https://substrait.io/ will gain traction and will be supported natively by databases", "why_is_quote": true, "has_verdict": false, "sentiment": {"recommend": 6, "neutral": 0, "compare": 0, "warn": 0}, "spark": [0, 0, 0, 2, 1, 0, 0, 0, 1, 1, 1, 0], "listed": true, "loved": [], "caveat": "", "short_quote": "I hope https://substrait.io/ will gain traction and will be supported natively by databases", "kind": "", "icon": false, "domain": "substrait.io", "github_repo": null, "official_url": "https://substrait.io", "pricing": "", "aliases": ["Substrait"], "verdict": null, "praise": [{"label": "", "summary": "", "quotes": [{"id": 794790080, "item_id": 49674380, "url": "https://news.ycombinator.com/item?id=49674380", "by": "riordan", "date": "2026-09-12", "stance": "recommend", "quote": "Substrait[0] is still the IR for query plans across different execution engines", "excerpt": "We haven\u2019t decided that\u2014Substrait[0] is still the IR for query plans across different execution engines\u2014but projects like QueryBrew are a great side effect of what a SOTA planner can accomplish. [0]: https://substrait.io", "context": "", "use_case": "", "switched_from": "", "story": "QueryBrew: System-Agnostic SQL-to-SQL Query Optimization [pdf]"}, {"id": 789561072, "item_id": 49347567, "url": "https://news.ycombinator.com/item?id=49347567", "by": "exidex", "date": "2026-08-18", "stance": "recommend", "quote": "Hance the mention of Substrait.", "excerpt": "Just as with any kind of programming I want to be able to detect as much amount of issues as early as possible. That includes issues like invalid queries (both on syntax and types level) but also stuff like will specific transaction isolation level be just enough (from correctness and performance point) for my specific use case, or will the migration query lock the whole db or take multiple days to execute because I ", "context": "", "use_case": "Cross-language query plans", "switched_from": "", "story": "Rethinking Database Programming"}, {"id": 789504400, "item_id": 49344025, "url": "https://news.ycombinator.com/item?id=49344025", "by": "exidex", "date": "2026-08-18", "stance": "recommend", "quote": "I hope https://substrait.io/ will gain traction and will be supported natively by databases", "excerpt": "I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported native", "context": "", "use_case": "", "switched_from": "", "story": "Rethinking Database Programming"}, {"id": 785799187, "item_id": 49112449, "url": "https://news.ycombinator.com/item?id=49112449", "by": "westurner", "date": "2026-07-30", "stance": "recommend", "quote": "substrait's portable query plans", "excerpt": "Would there be an advantage to reusing SIMD-optimized libraries for this? Polars Rust is built on Arrow and packed_simd. pola-rs/polars: https://github.com/pola-rs/polars polars - Rust API docs: https://docs.pola.rs/api/rust/dev/polars/#simd lancedb's data format; Lancedb/lance works with [Pandas, DuckDB, Polars, PyArrow,]; https://github.com/lancedb/lance Narwhals' df interface (Python) https://narwhals-dev.github.i", "context": "", "use_case": "portable query plans", "switched_from": "", "story": "Postgres rewritten in Rust v0.2, now faster than Postgres and ClickHouse"}, {"id": 759364114, "item_id": 47460257, "url": "https://news.ycombinator.com/item?id=47460257", "by": "mathisd", "date": "2026-03-20", "stance": "recommend", "quote": "see Apache Arrow, Substrait, Catalog", "excerpt": "Few observations related to data engineering in the context of a data warehouse: 1. Protocols and IR (Intermediate Representation) have layed and continue to enable interoperability and composability of data tools (see Apache Arrow, Substrait, Catalog). (great introduction here https://voltrondata.com/codex). 2. Current OSS data tooling is really good (except on user interface). 3. Agentic workflow are working incred", "context": "", "use_case": "Query plan interchange", "switched_from": "", "story": null}]}], "caveats": [], "who": [], "tags": [], "use_cases": ["cross-language query plans", "portable query plans", "query plan interchange", "standardized query plan ir"], "compared": [], "makers": [], "threads": [{"url": "https://news.ycombinator.com/item?id=49342530", "title": "Rethinking Database Programming", "mentions": 2}, {"url": "https://news.ycombinator.com/item?id=49666155", "title": "QueryBrew: System-Agnostic SQL-to-SQL Query Optimization [pdf]", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=49111925", "title": "Postgres rewritten in Rust v0.2, now faster than Postgres and ClickHouse", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47438930", "title": "item 47438930", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=47099980", "title": "Pipelined Relational Query Language, Pronounced \"Prequel\"", "mentions": 1}, {"url": "https://news.ycombinator.com/item?id=46908700", "title": "Waiting for Postgres 19: Better Planner Hints with Path Generation Strategies [video]", "mentions": 1}], "sentiment_by_month": {"2025-11": {}, "2025-12": {}, "2026-01": {}, "2026-02": {"recommend": 2}, "2026-03": {"recommend": 1}, "2026-04": {}, "2026-05": {}, "2026-06": {}, "2026-07": {"recommend": 1}, "2026-08": {"recommend": 1}, "2026-09": {"recommend": 1}, "2026-10": {}}, "quotes": [{"id": 794790080, "item_id": 49674380, "url": "https://news.ycombinator.com/item?id=49674380", "by": "riordan", "date": "2026-09-12", "stance": "recommend", "quote": "Substrait[0] is still the IR for query plans across different execution engines", "excerpt": "We haven\u2019t decided that\u2014Substrait[0] is still the IR for query plans across different execution engines\u2014but projects like QueryBrew are a great side effect of what a SOTA planner can accomplish. [0]: https://substrait.io", "context": "", "use_case": "", "switched_from": "", "story": "QueryBrew: System-Agnostic SQL-to-SQL Query Optimization [pdf]"}, {"id": 789561072, "item_id": 49347567, "url": "https://news.ycombinator.com/item?id=49347567", "by": "exidex", "date": "2026-08-18", "stance": "recommend", "quote": "Hance the mention of Substrait.", "excerpt": "Just as with any kind of programming I want to be able to detect as much amount of issues as early as possible. That includes issues like invalid queries (both on syntax and types level) but also stuff like will specific transaction isolation level be just enough (from correctness and performance point) for my specific use case, or will the migration query lock the whole db or take multiple days to execute because I ", "context": "", "use_case": "Cross-language query plans", "switched_from": "", "story": "Rethinking Database Programming"}, {"id": 789504400, "item_id": 49344025, "url": "https://news.ycombinator.com/item?id=49344025", "by": "exidex", "date": "2026-08-18", "stance": "recommend", "quote": "I hope https://substrait.io/ will gain traction and will be supported natively by databases", "excerpt": "I think, the reality is SQL being simply to old to coexist with a web app use case. All the nice things that article talks about are not possible to nicely integrate with SQL. Current development is done by either writing SQL by hand or by letting ORMs to autogenerate it. Both feel bad because of how bad SQL is. But there is no other option. I hope https://substrait.io/ will gain traction and will be supported native", "context": "", "use_case": "", "switched_from": "", "story": "Rethinking Database Programming"}, {"id": 785799187, "item_id": 49112449, "url": "https://news.ycombinator.com/item?id=49112449", "by": "westurner", "date": "2026-07-30", "stance": "recommend", "quote": "substrait's portable query plans", "excerpt": "Would there be an advantage to reusing SIMD-optimized libraries for this? Polars Rust is built on Arrow and packed_simd. pola-rs/polars: https://github.com/pola-rs/polars polars - Rust API docs: https://docs.pola.rs/api/rust/dev/polars/#simd lancedb's data format; Lancedb/lance works with [Pandas, DuckDB, Polars, PyArrow,]; https://github.com/lancedb/lance Narwhals' df interface (Python) https://narwhals-dev.github.i", "context": "", "use_case": "portable query plans", "switched_from": "", "story": "Postgres rewritten in Rust v0.2, now faster than Postgres and ClickHouse"}, {"id": 759364114, "item_id": 47460257, "url": "https://news.ycombinator.com/item?id=47460257", "by": "mathisd", "date": "2026-03-20", "stance": "recommend", "quote": "see Apache Arrow, Substrait, Catalog", "excerpt": "Few observations related to data engineering in the context of a data warehouse: 1. Protocols and IR (Intermediate Representation) have layed and continue to enable interoperability and composability of data tools (see Apache Arrow, Substrait, Catalog). (great introduction here https://voltrondata.com/codex). 2. Current OSS data tooling is really good (except on user interface). 3. Agentic workflow are working incred", "context": "", "use_case": "Query plan interchange", "switched_from": "", "story": null}, {"id": 753984146, "item_id": 47124009, "url": "https://news.ycombinator.com/item?id=47124009", "by": "data_ders", "date": "2026-02-23", "stance": "recommend", "quote": "projects like Google's zeta-sql [1] and Substrait [2] get more traction", "excerpt": "I'm as big a SQL stan as the next person and I'm also very skeptical anytime anyone says that SQL needs to be replaced. At the same time, it's challenging that SQL cannot be iteratively improved and experimented upon. IMHO, PRQL is a reasonable approach to extending SQL without replacing SQL. But what I'd love to see is projects like Google's zeta-sql [1] and Substrait [2] get more traction. It would provide a more s", "context": "", "use_case": "Standardized query plan IR", "switched_from": "", "story": "Pipelined Relational Query Language, Pronounced \"Prequel\""}, {"id": 750734432, "item_id": 46920902, "url": "https://news.ycombinator.com/item?id=46920902", "by": "sidpatil", "date": "2026-02-06", "stance": "recommend", "quote": "You might be interested in Substrait", "excerpt": "You might be interested in Substrait (https://substrait.io/).", "context": "", "use_case": "", "switched_from": "", "story": "Waiting for Postgres 19: Better Planner Hints with Path Generation Strategies [video]"}]}