Until 1.0, PeachQ's version is its q-conformance pass rate. 0.41 means 41% of the conformance suite passes today. The suite grows as PeachQ covers more of q, so the number tracks tested behaviour, not a marketing target.
Every new q behaviour needs tests. As more of the corpus turns green, the version number moves with it. New tests can raise the bar, so progress is measured against the current public suite.
PeachQ is already useful for experiments, coding challenges and exploring a free q-like environment. It also has strong performance foundations through Rayforce. It is not yet a drop-in q replacement: important areas such as char and string semantics, on-disk storage, and parts of the long-term architecture are still undecided or unimplemented.
We are looking for people who want to discuss those choices, try real workloads, and help shape the roadmap. If that sounds useful, please get in touch.
The goal: pass every test we have. 1.0 lands when PeachQ runs the full conformance corpus green: language, datatypes, qSQL, tables, joins, and IPC.
select, exec, update, delete, grouping, functional querieslj, ij, uj, aj family on keyed tablesWith the language solid, PeachQ will be tested with partners against real platforms and their own suites: the behaviours that matter in production, not only the reference docs.
PeachQ aims to pair the in-memory q engine with DuckDB as its storage layer: durable storage, SQL, Parquet, and access to a fast-growing data ecosystem.
Pieces may land earlier, but 2.0 is when the DuckDB story should be production-solid: q tables backed by DuckDB, query pushdown, and drivers that speak the kdb wire.
k) language beneath q - PeachQ targets q, not the underlying k dialect and escape hatch