ROrobert3005·Jan 27, 2026
Not to be confused with Velox a compute engine https://github.com/facebookincubator/velox/
In Velox: A Port of Tauri to Swift by Miguel de Icazafacebookincubator
velox
C++2022–2026
facebookincubator / velox
velox
A composable and fully extensible C++ execution engine library for data management systems.
8Distinct people
8Mentions
0Explicit recommenders
4.3KGitHub stars
What to know before exploring
What it is
A composable and fully extensible C++ execution engine library for data management systems.
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 year8 dated mentions
Observed mentions: 2022-03-18 14:15:56 UTC to 2026-01-27 11:15:49 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 |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
8 sourcesVelox: A composable and extensible C++ execution engine library
7 points · Open discussionPython's Substrait seems like the biggest/most-used competitor-ish out there. I'd love some compare & contrast; my sense is that Substrait has a smaller ambition, more wants to be a language for talking about execution rather than a full on optimization/execution engine. https://github.com/substrait-io/substrait .
(Edit: ah, there's a recent talk discussing PyVelox trying to get Substrait integration. https://www.youtube.com/watch?v=l_kHxkGkNRg#t=18m22s . However there's also discussion about the un-maintainedness of some of the current Substrait work here; unclear status. https://github.com/facebookincubator/velox/issues/8895)
We can also see from the Apache Arrow DataFusion discussion that they too see themselves as a bit of a Velox competitor. https://github.com/apache/arrow-datafusion/discussions/6441
It's cool to see this space matur
Read the rest
e. I like that even Velox sees that Apache Arrow (underlying Apache Arrow DataFusion too) is industry standard tech that they ought work with. https://engineering.fb.com/2024/02/20/developer-tools/velox-...
Theres a solid Influx post talks to some of how they are composing the assorted technologies to build they next gen 3.0, which I find helpful for getting a sense of how all the pieces of a modern high-performance data engine slot together. https://www.influxdata.com/blog/flight-datafusion-arrow-parq...
Meta Velox: A C++ vectorized database acceleration library
2 points · Open discussionA C++ vectorized database acceleration library
2 points · Open discussionA new C++ vectorized DB acceleration library, optimizing query engines
2 points · Open discussionThey are targeting the same problem as ANSI SQL or ZetaSQL, but at a lower level. The standardized SQL dialects allow a common way for authors to express a computation. Query engines parse SQL into a "Logical Plan" (LP), which is a graph (generally a DAG) of transformation nodes, and edges representing data flow. For example, `SELECT a FROM t WHERE b > 0` would become something similar to:
PROJECT([COLUMN("a")])
<-
FILTER(EXPRESSION(COMPARE(COLUMN("b"), LITERAL(0), GREATER_THAN)))
<-
READ_TABLE(["a", "b"], TABLE("t"))
Currently, most engines have their own logical plan representation, with its own serialization, etc. This prevents several things that would be nice:
1. Alternative front-ends to get the LP that are not parsing SQL (eg, dataframes or builders). For example, Spark allows multiple ways to create an LP: SQL, Scala Dataset,
Read the rest
etc, but this only works for Spark.
2. Standardized tools to analyze, display, store, etc LPs.
3. Cross-communication to different back-ends that will convert the LP to a lower-level representation (eg, execution plan or distributed plan).
4. Reusing other engines LP (they have a lot of similarities), so a new engine will have to re-invent the wheel.
Substrait is providing a standard, cross-language and cross-engine compatible Logical Plan (although people disagree on exactly the definition of LP so they describe it differently). Apache Calcite is another project that is addressing the same space, although it has more components (a SQL parser, etc). The Substrait project has historical ties to Calcite, and they describe why they chose their approach.
Another way of looking at it is that modern query engines have four macro steps:
1. Getting an LP (usually from parsing SQL).
2. Converting the LP to a "physical execution plan", possibly a distributed plan.
3. If distributed, requisitioning workers and distributing the execution sub-plans to them.
4. The workers (if distributed) or the engine (if single-box) executing the execution plan, by performing the actual computations on actual bytes.
(Note that this is a cartoon version and any given engine will have differences, eg Presto/Trino does not have a clear distinction between LP and Physical Plan.)
1) and 4) are broadly similar across engines, while 2) and 3) vary widely partially because of different requirements (reliability, latency, etc). Projects such as Apache Arrow and Velox (https://github.com/facebookincubator/velox) are making common tools for 4), and as mentioned ANSI SQL, ZetaSQL, Calcite, and Substrait are making common tools for 1).