clickhouse-js-node-rowbinary
Skill563 starsChanged 9 months agoApache-2.0View on GitHub
Generate TypeScript/JavaScript code that reads/decodes AND writes/encodes ClickHouse RowBinary streams for the ClickHouse HTTP server. Use this skill whenever a user wants to parse or produce `RowBinary`, `RowBinaryWithNames`, or `RowBinaryWithNamesAndTypes`. Node.js only, doesn't cover browsers.
1 other project uses a version of this.
Adopted by
Most recently taken up by
- ClickHouse/clickhouse-jsword for word, first seen Oct 8, 2026
Other versions1 project uses a version of this.
Word for word · 1
- ClickHouse/clickhouse-js★ 331100% same
Edited · 0
None found.
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository15 other files it gives its agents.
- AGENTS.mdAGENTS.md
- skills/clickhouse-architecture-advisor/AGENTS.mdAGENTS.md
- skills/clickhouse-best-practices/AGENTS.mdAGENTS.md
- skills/clickhouse-js-node-rowbinary/AGENTS.mdAGENTS.md
- skills/clickhouse-managed-postgres-rca/AGENTS.mdAGENTS.md
- chdb-datastoreSkill
- chdb-sqlSkill
- clickhouse-architecture-advisorSkill
- clickhouse-best-practicesSkill
- clickhouse-js-node-codingSkill
- clickhouse-js-node-troubleshootingSkill
- clickhouse-managed-postgres-rcaSkill
- clickstack-otel-collectorSkill
- infra-clickhouseSkill
- infra-postgresSkill
The file
Files
ClickHouse JS RowBinary Codec Generator for Node.js
This skill generates both directions of the wire format: readers (decode bytes → values) and writers (encode values → bytes, the mirror). A given task normally needs only one side. This file is the shared entry point — the format gate plus the principles common to both directions; the per-direction decisions, guidance, and the per-type reference tables live in two sibling files.
Pick your side — read only the one you need:
- Decoding a
RowBinary*response from ClickHouse into JS values → reader.md. Streaming vs whole-buffer, row-objects vs columnar, fixed vs runtime schema, and the per-type reader reference. - Encoding JS values into a
RowBinarypayload to send to ClickHouse → writer.md. TheSink/writeXbuilding blocks,writeRowsstreaming, and the per-type writer reference.
The per-type code is real, split by direction under src/readers/ and
src/writers/.
First: is RowBinary even the right format?
RowBinary exists for throughput, but it is not automatically the fastest path — match the format to the shape of the data before committing to a bespoke parser.
Prefer a JSON* format (e.g. JSONEachRow) when the result is mostly
strings / JSON-like values that you consume wholesale — randomly accessing
essentially every field, running string/regexp methods on them, treating values
as text. V8's native JSON.parse is heavily optimized C++ and builds JS strings
and objects faster than a JS-level RowBinary decoder can; pair it with HTTP
response compression (gzip / zstd, which crushes JSON's repetitive keys) and
the wire cost shrinks too.
RowBinary clearly wins when the result is dominated by:
- Wide numerics —
Int128/Int256/UInt128/UInt256,Decimal128/Decimal256. - Binary / fixed-width blobs —
IPv4,IPv6,UUID,FixedString. - High-volume fixed-width numeric columns generally, where each value is a
single
DataViewread.
Prefer the Native format when columnar load and client-side analytics are
the main goal (fold/scan/filter columns, feed typed arrays to a Worker or WASM).
Native is column-major, so it loads straight into one typed array per column
with no transpose.
For help choosing and consuming a JSON* format (or CSV / TSV) instead, use the
clickhouse-js-node-coding skill.
Core guidance (both directions)
These principles apply whether you are generating a reader or a writer; the side-specific operational guidance is in reader.md / writer.md.
- Little-endian only. RowBinary is little-endian; target x86/ARM. Read and
write every multi-byte number with
DataViewaccessors passing a literaltruefor thelittleEndianflag. - Correct first, then optimize. First emit a correct codec built from the plain per-type API. Only after it's correct (and tested) specialize it. Don't bake performance assumptions in before correctness.
- Monomorphize generic/composite types. Emit specialized, inlined code per type combination instead of passing functions as arguments where the type is known ahead of time.
- Inline the leaf ops. The per-type
readX/writeXfunctions are the correct, composable reference; the generated codec should INLINE their bodies, not call them, so the row loop is straight-line with no per-field indirection (and so the fixed-width coalescing can fold the offset arithmetic together). - Annotate the type per column. Inlining erases the type structure, so put a short comment above each column's encode/decode block naming the ClickHouse type it handles.
- Shared scratch is not reentrant. Some hot methods reuse a module-level
scratch buffer as a write-then-read pair — correct only because the access is
fully synchronous. An
async/yieldboundary between populating and reading it corrupts the value. - TypeScript by default. Generate TypeScript code and helpers unless the user explicitly asks for plain JavaScript.
Worked examples
Six end-to-end examples with real speedup are catalogued in EXAMPLES.md.
Out of scope
- JSON / CSV / TSV / Parquet parsing → use
clickhouse-js-node-coding. - Connection errors, hangs, type mismatches → use
clickhouse-js-node-troubleshooting. - Browser / Web Worker / Edge →
@clickhouse/client-web.
Still Stuck?
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

