cd /news/developer-tools/show-hn-litelink-local-first-embedde… · home topics developer-tools article
[ARTICLE · art-120256] src=github.com ↗ pub= topic=developer-tools verified=true sentiment=· neutral

Show HN: Litelink – local-first, embedded stream capture into Iceberg tables

Developer nhobin219 released litelink, a local-first, embedded Python library for capturing WebSocket streams directly into Apache Iceberg tables, designed for small VMs (2 vCPU, 8GB RAM) to avoid managing Kafka, Postgres, or CDC connectors. The library, which is heavily AI-generated but human-reviewed, supports a single writer per stream and aims to eliminate the small-file problem and maintenance overhead, with end-to-end setup under five minutes. The project is available on GitHub and PyPI.

read2 min views1 publishedSep 3, 2026

Show HN: litelink - local-first, embedded stream capture into Iceberg tables

Hi HN! I just wanted to share litelink a local-first, embedded capture library I built in python (code is heavily AI generated but designed and reviewed by yours truly). Litelink supports a single writer per stream.

I've been doing a lot of development and deployments on tiny VMs (2 vCPU, 8GB, 50-100GB disk) and didn't want the complexity or cost of managing central brokers (Kafka), databases (Postgres), and CDC/connectors just to get queryable WebSocket stream capture running.

With litelink, you configure a log in code, and end-to-end setup takes <5 minutes (see the example scripts in the repo). The log is itself an Iceberg table (actually two: a local and archive table), so there's no second copy of your data to keep in sync or connector to manage.

I'm sure there are still bugs, but I recently migrated all the capture feeds for a personal research project to litelink, and the experience has been night and day. Before that, I'd hand-rolled a capture system and was dealing with all the issues you'd expect:

  • The small file problem (the worst single stream contained 200,360 files averaging 46 KB some files literally containing zero rows)

  • Managing compaction and retention

  • Managing a custom hive-partitioned layout on disk and in S3

  • In-memory buffering that cost data on SIGKILL

Ingesting data is easy(ish). Maintaining it is not. That's exactly why I wrote litelink (so you don't have to think about maintenance). I'll post some before/after stats in a comment below. Also, the hand-rolled capture wasn't actually durable (due to the in-memory buffering) and litelink capture is. You can read about the design and exactly how it works in the docs in the repo. Feel free to ask any questions here though :)

I tried to channel the same ethos as LanceDB/Iceberg/SQLite. Everything runs local first without a network connection required. I've tried to abstract the complexity of stream/data lifecycle maintenance away behind a few public library methods. Hopefully someone else finds this useful! Let me know what you think.

repo: [https://github.com/nhobin219/litelink](https://github.com/nhobin219/litelink)

spec: [https://github.com/nhobin219/litelink/blob/main/docs/SPEC.md](https://github.com/nhobin219/litelink/blob/main/docs/SPEC.md)

pypi: pip install litelink

Comments URL: [https://news.ycombinator.com/item?id=49549760](https://news.ycombinator.com/item?id=49549760)

Points: 1

── more in #developer-tools 4 stories · sorted by recency
── more on @nhobin219 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/show-hn-litelink-loc…] indexed:0 read:2min 2026-09-03 ·