Recent submissions

Comment · 1 year ago
Comment · 1 year ago
Thanks, your Redis story sounds exactly like my motivation. When the cache layer becomes the primary persistence and you’re pushing around millions of JSON-encoded Pydantic objects, the overhead hits both RAM and the bill very quickly. That pain is real.

Regarding getting this into Pydantic core: I doubt the maintainers would want to ship and maintain a binary serialization layer inside the main project. That said, it might still be worth opening an issue to hear their perspective - worst case, it becomes a documented "won’t include".

As for continuity and lock-in concerns - my primary production workload depends on this library, so I fully intend to keep it updated alongside new Pydantic and Python releases. I also intentionally designed it with minimal dependencies: core functionality uses only pydantic and typing-extensions. The only extra is leb128, and that’s just for UInt128, which almost nobody truly needs - I’m considering moving that to an optional extra to keep the base install even leaner.

Comment · 1 year ago
I ran into memory issues with a high-load project so I built a compact binary encoder/decoder for Pydantic models. It cut in-RAM object size by up to 7× vs json.dumps(), and ended up saving the whole service from collapsing.

GitHub: https://github.com/sijokun/PyByntic

Works with annotated Pydantic models and gives you: – .serialize() -> bytes – .deserialize(bytes) -> Model

Curious to hear whether others here have hit similar problems and how you solved it?

P.S. Project was a Telegram MiniApp with 10m+ MAU, we were storing cached user objects in Redis Cluster

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton