the_precipitate

With DRAM price this high, this is certainly a welcome feature. But how do you control write latency? B+ Tree is pretty bad at updates and LMDB, another BTree based storage is lightning fast on reads but quite bad on writes compared with RocksDB.

FerretDB and DocumentDB seem to be the only other two Mongo-compatible open source database implementations. Both are based on PostgreSQL.

I've been testing EloqKV against TiKV, and it's much faster, specially for in-memory reads. I was seeking an alternative solution to replace KVRocks, which is essentially just a single node RocksDB wraped with a Redis API, EloqKV easily outperforms it by a large margin. Moreover, EloqKV can scale to multiple nodes.

I personally think that using the Redis API as a real database interface is quite useful. It saves me from dealing with the complexity of SQL, and it’s very natural to map my needs into Redis data structures. Coming from a programming background rather than a traditional DB background, I find imperative programming far more intuitive than declarative SQL, which I cannot "compile in my head" as easily.

Overall, kudos to the team for building such a solid solution and making it open source under a proper GPL license, which is becoming rare for new databases these days.

My understanding is that they have a common layer over which they hold full copyright, so they can license it however they like. But since this software is also used in EloqSQL (which includes MariaDB code) and EloqDoc (which includes MongoDB code), the license has to be compatible with both. That’s why they state that the code can be licensed under either license (note the OR part).

I doubt they would accept any code that cannot be re-licensed, because the common layer essentially “transmits the infection,” for lack of a better way to describe it.

Thanks! I remember that for a long time Aerospike didn’t support transactions, and I just found out they rolled out this feature just a few months ago. I’ve always been a bit suspicious of NoSQL databases that add transaction support late in their lifecycle. MongoDB seems to fall into the same category, and its transaction support is, to say the least, rather unsatisfying.

I have tried TiKV and TiDB but they are quite slow. EloqKV is much faster, especially for in-memory reads. I use it to replace KVRocks, which is just a single node KV store wrapper around RocksDB with a Redis API, and EloqKV nicely outperforms it.

I have tested EloqKV for a pet project and seems it is quite solid. Performance is fantastic, far out-performing most databases with durability by a large margin. I am not sure about the distributed transaction correctness but all my tests seem to indicate it works as advertised, which is very interesting because the other distributed NewSql databases are all rather slow. Haven't tried their SQL and Mongo solutions, but they also look quite interesting.

Kudos. Haven't seen many serious databases that are open sourced (GPL) instead of "SSPL" or "Source Available" for a while.

To really appreciate inverted indexes, it’s worthwhile to study ISR (Inverted Stream Readers), a concept introduced by the great Mike Burrows. It’s also worth exploring encoding techniques like PForDelta. These elegant ideas demonstrate how true systems design masters can distill complex concepts into simple, powerful abstractions.

Edit: I stand corrected: it's called index stream readers (thanks atombender for pointing this out). For those who knows Mike Burrows only for the Burrows-Wheeler transformation (BZip), you might also want to know that he was also one of the main developers of AltaVista, the first real search engine for the internet. He also designed the early versions of Bing search engine. Eventually he worked for Google and designed their lock service called Chubby.

And you do know that .exe file is wasteful, .com file actually saves quite a few bytes if you can limit your executable's size to be smaller than 0xFF00h (man, I am old).

Self taught means you are self-motivated. You are not just looking at it as a job. That's why code quality is better. Interest is the most strong driving force for one to improve.

TCP-in-UDP keeps TCP's battle-tested logic but wraps it to bypass middleboxes—great for legacy systems. QUIC is a clean-slate rewrite, better for new apps. Tradeoff: compatibility vs modern features.

Yeah, and this doesn't seems to be that useful. At least I don't understand why one should do this on a strong ACID relational database.

I think one of the main issue is that the 10x or 100x talents in AI have not yet really show their value yet. None of these AI companies are making any money, and they are valued over highly successful and profitable companies out there because of their "potentials". ARR is nothing if you sell goods valued at 1 dollar for 90 cents.

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.

This is really interesting! The performance looks impressive. I’ve always struggled with the Redis/MySQL two-tier architecture because they are two completely different systems. Porting an application is always tricky due to API incompatibility, and maintaining consistency between the two is a huge hassle. If there’s any issue on the cache side (like performance jitters or a few servers going down), the DBMS part can quickly get overwhelmed. This kind of cascading failure is a common problem in distributed systems. There are some great discussions on this topic over at https://danluu.com/cache-incidents/. BTW, although the formatting is a bit rough, it's a great read for anyone interested in caching. Back to the topic, I always hoped that new advancements in database systems can alleviate or eliminate this problem, your work seems to be on the right track.