Thank you, Andy! This is Jeff, CEO and Chief Architect of EloqData. It's a great honor for us to have THE Andy Pavlo join the discussion on our first HN submission.

If I remember correctly, NuoDB uses a shared cache with a cache coherence protocol, whereas EloqKV uses a shared nothing (partitioned) cache. The former is a local read but needs to broadcast each write to all nodes. The latter has no broadcast for writes but may be a remote read. The tradeoff is evident and we are actively exploring opportunities to strike a balance, e.g., for frequently-read, rarely-write data items, use the shared cache mode.

We appreciate you pointing us to the CIDR paper. I had the pleasure of working with Phil for some time and fondly remember many discussions with Phil on various topics many years ago. To address your question, yes, we've been trying to solve the research challenges presented in the CIDR paper. The devil is in the details. We've developed numerous new algorithms and invested significant engineering effort into the design and implementation of our products. The benefits are as follows:

- Optimality: We believe we have an overall design that optimizes synchronous disk writes and network round-trips. For instance, when the design is reduced to a single node, its performance matches or exceeds that of single-node servers. As you might expect, a lot of innovation has gone into making distributed transactions as efficient as non-distributed ones, comparable to those in MySQL or PostgreSQL.

- Modularity: Our architecture allows us to easily replace the Parser/Compute layer and Storage/Persistence layer with the best existing solutions. This means we can create new databases by leveraging existing parsers and compute engines from current database implementations to achieve API-compatibility, as well as leveraging existing high-performance KV stores for the persistence layer. This allows us to avoid reinventing the wheels and to take advantage of decades of innovations in the database community.

- Scalability: The entire system operates without a single synchronization point—not even a global sequencer. We drew many inspirations from the Hekaton and your TicToc paper. All four types of resources (CPU, Memory, Storage, Logging) can be scaled independently, as we mentioned earlier. More importantly, they can scale dynamically to accommodate workload changes without service disruptions.

We look forward to sharing more technical details as we move out of stealth mode. I hope to continue this conversation with you in person in the near future.

Thank you for your interest. I agree—if Redis (as a cache) and MySQL (as a store) are deployed separately, we can only achieve eventual consistency. That’s precisely why we’re integrating cache and storage into a single system, much like EloqKV.

Yeah, it's just a happy coincidence that our product release lined up with the Redis license change. We think EloqKV is a way more powerful and versatile product than Redis. It can definitely be used as a simple in-memory cache, just like Redis, Valkey, or Dragonfly. But the real strength of EloqKV is in its full database capabilities: scalability, consistency, and high availability, all the things you'd expect from a modern database.

Playing devil’s advocate here, I do have some doubts about the future dynamics between open source and database systems. Andy Pavlo mentioned in his CMU DB course that nowadays new database companies are either fully closed-source or only open a small portion of non-essential code.

If you think about it, databases are arguably a more critical piece of IT infrastructure than cybersecurity products. Yet, while cybersecurity companies are thriving with many company valuations exceeding $10 billion, database companies—especially those embracing open source—struggle to achieve similar commercial success. The few database companies that do reach high valuations are typically based on closed-source products, while those adopting open-source models often face significant challenges in becoming profitable.

It's also worth noting that many companies in the database space have recently changed their licenses around open source or source availability. If major players like MongoDB, ElasticSearch, and Redis are all making these tough decisions to build sustainable businesses, it might not be fair to simply blame corporate greed. Without adequate returns on investment, venture funding for database development could dry up, which would ultimately stifle innovation in this crucial sector.

We are not yet open sourcing the code on our github site yet. The current release is a prebuilt binary, user can do whatever you want with the software (there is a license file in the downloaded tarball), EloqKV is not yet production ready, so please don't use it in a production environment.

We are a small team of developers, and currently EloqKV is still under heavy development. We would like to maintain agility and quickly iterate and improve our product with consistency with our customer's feedback. However, we are actively evaluating multiple paths to open sourcing our technology and any suggestions and concerns will certainly be kept in our mind as we progress.

If it's not open-sourced, I’m not going to use it to store my critical data. Just saying...