Hacker News
points by hubertzhang 4 days ago | 0 comments
Back in 2018, when I was at Greenplum, my team worked through The Internals of PostgreSQL together alongside Andy Pavlo’s CMU database courses. It was invaluable for anyone working on the database kernel. Today, a beginner can get that same interactive learning experience simply by chatting with AI, much like the discussions our team had back then.

Now I’m building Lavik, a new cache service for PostgreSQL. Traditional caches like Redis are DRAM-based, so they can only hold a small slice of hot data. Once your data outgrows memory, you’re exposed to cache miss storms, where a flood of requests falls through to PostgreSQL all at once. Nobody likes those. (OpenAI encounter the similar cache miss storms problem: https://openai.com/index/scaling-postgresql/)

Lavik takes a different path: it runs on NVMe SSDs, and it’s still faster than Redis running on DRAM. That’s not what most people expect. Conventional wisdom says SSD-based systems trade speed for capacity, but Lavik gives you both. You can keep TB-scale data in cache while getting 1M QPS and sub-millisecond P99 latency.

Lavik is open source under the Apache License. GitHub: https://github.com/eloqdata/lavik Website: https://lavik.dev

[–] daniele_dll 3 days ago
GET and SET (and similar) are easy, let me know if you keep the same performances once you start to need RMW operations or even transactions to deal with multi keys commands or add clustering support :)

Also going faster than Redis doing only GET and SET is fairly easy, the very very very early versions of cachegrand (pre 0.1) were doing well over 100M/s of GET and SET on a 32 core / 64 threads machine with pipelining.

Once you start to chuck the rest to make it actually "usable" it's where you start to massively lose performances.