We're launching CodeDB v0.2.53!

538x faster than ripgrep. 569x faster than rtk. 1,231x faster than grep.

0.065ms code search. Pre-built trigram index. Query once, instant forever.

21 issues closed. 14 PRs merged. 7 contributors. One weekend. Benchmarked on rtk-ai/rtk (329 files):

codedb search: 0.065ms
rtk: 37ms
ripgrep: 45ms
grep: 80ms

codedb word lookup: 0.013ms. That's 13 microseconds. For an exact match across 329 files.

First index: 126ms. Then sub-millisecond everything. Forever.

WE built a code intelligence server in Zig that gives AI agents up to 469x faster queries than grep/find.. and hear this.. uses 92x fewer tokens.

0.2ms lookups. 3.9ms symbol search. Indexes once, then every query hits memory. No filesystem scans. No raw text dumps. 0 embeddings. Every time an AI agent runs grep or find on your codebase, it pays the full cost.

Filesystem scan. Raw text dump. Thousands of tokens for a simple lookup.

grep a symbol across 7k files: 763ms, 7.7KB response.
codedb: 3.9ms, 4.4KB. Same answer. 200x faster. Half the bytes. Half the tokens, half the costs.

I replaced FastAPI's entire HTTP core with Zig.

Same decorator API. Same Pydantic models. 7× faster.

47,832 req/s vs FastAPI's 6,800. 2.09ms p50 latency.

Introducing. TurboAPI.

Here's the story.. FastAPI is beautiful to write. But every single request goes:

uvicorn → ASGI → Starlette → your handler

JSON parsed in Python. Response serialized in Python. GIL held throughout.

At inference-serving scale, this hurts.

Won honorary mention at @GoogleDeepMind hackathon Singapore for EmergentDB! 🏆

A PoC vector DB using MAP-Elites with 3D behavior space (Recall × Latency × Memory) to auto-evolve optimal index configs.

51x faster than ChromaDB. 100% recall.

Link below 🧵👇

The problem with vector databases today:

• Manual tuning hell (HNSW M=16? M=32? ef=100?)
• Configurations that work for 1K vectors fail at 100K
• You're forced to choose between speed and accuracy

What if the database could optimize itself? 🤔github.com/justrach/emerg…