TorQ: Kdb+ Production Framework
tosh
30 points
4 comments
May 22, 2026
Related Discussions
Found 5 related stories in 85.8ms across 8,303 title embeddings via pgvector HNSW
- Show HN: Torrix, self hosted, LLM Observability,(no Postgres, no Redis) AdarshRao23 · 29 pts · May 13, 2026 · 56% similar
- TurboQuant: Building a Sub-Byte KV Cache Quantizer from Paper to Production wizzense · 13 pts · March 27, 2026 · 54% similar
- TurboQuant: Redefining AI efficiency with extreme compression ray__ · 509 pts · March 25, 2026 · 49% similar
- Show HN: Pg_deltax, Apache-licensed alternative to TimescaleDB tee-es-gee · 27 pts · May 19, 2026 · 48% similar
- QBE – Compiler Back End smartmic · 88 pts · May 08, 2026 · 48% similar
Discussion Highlights (3 comments)
anonu
This used to be aquaq. What happened? I liked this framework when I used it years ago but I've become disillusioned with kdb. I can ask Claude to write specialized rust based tick processing tools so quickly now. So the baseline use case for kdb is eroded away, at least for me. I love kdb as a distributed services framework. But if I can write it with redis and python with Claude support in all the boilerplate I'm more likely to go that route.
dgellow
Can we get an eli5?
bjconlan
If you're looking to use this with the community edition I would recommend reading through https://dataintellect.com/blog/running-torq-with-kdb-x-commu... as they outline some of the factors that need consideration. I really do love what kdb is doing but I think maybe they lost too much momentum (and confidence) when back flipping on previous agreements for the community editions. (Which I don't think they will again with the kdb-x releases as they have a good balance this time) It would have been nice to see torqx just work (tm)