Hacker News Reader

Comment by convolvatron | Hacker News Reader

this is kind of a strange design. in order to support this we build an external model of the database for all potentially conflicting state. wouldn't it be easier to make a redis lookalike that supported high isolation levels?

View on HN

The external model is much simpler to do for Redis than a database with complex cross-key queries like an SQL database. Redis has scans but no queries or “real” transactions with rollback. To me it sounds like more work to implement MemoryDB and then additionally re-implement the Redis interior than to implement MemoryDB and use the off-the-shelf Redis.

I also think that the decoupled design is kind of elegant, it allows the logical implementation to be developed independently of the durability bits. It’s open-core but someone else is building the core.

Yes, it does seem like all that effort to wrap redis is wasted, and that it’d be easier to just create their own. It isn’t clear to me why this is better than creating their own. Does anyone know why they would go the route of trying to wrap something around redis rather than just replace it with something that has a redis compatible API?

They also likely have technology / libraries / expertise that make building the tracker straightforward.

It's smart because you have deep control of bugwards compatibility, and can swap parts of the stack later.

Reply on news.ycombinator.com