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.
Having Open Source Project on GitHub does not mean you need to become less agile. First there will not be instantly 1000 of people sending you pull requests, second even if they do - you have no obligation to take them in.
However if you say, we can write crap code... and no one would know because they only see binaries, this is not really a way gain a good confidence
In my opinion those days just having a "binary you can use" is the worst way to go for something like database/data store. If you are not sure about your Open Source plans having something like SaaS solution with free tier so users can experiment easily could be way to go
Thank you for the suggestions. We are currently developing a cloud-native version of EloqKV, with both Serverless and BYOC (Bring Your Own Cloud) options underway. The binary is a technology preview for those interested in experiencing the new architecture. EloqKV is built with a cloud-native focus, featuring a quaternary decoupling architecture that enables independent scaling of CPU, memory, storage, and logging. This design maximizes cloud elasticity for optimal scalability and resource efficiency. So I completely agree with the suggestion to offer a SaaS solution, allowing users to experiment.
AGPL is open source but also seems to defend against large companies and cloud providers using without paying for a license. With a contributor agreement in place you can sell a different license to them.
DB sales of open source are based on cloud and security. You can keep some security as open core along with cloud deployment.
Open source is about expanding the total potential market even if you only capture a portion of the value there.
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.
I second this. It's too risky and simply not worth it. Nevertheless, I find this "optional ACID" thing interesting. Many years ago when I was a graduate student, NoSQL was a big thing. It was widely claimed that transactions were expensive and you had to drop them in exchange to scale. I always had this question that if transactions were the culprit, why not turning them off? I later found that the relational system is such a monolith that everything (caching, concurrency control, logging, locking) is wired together in an extremely complex way and there is simply no "turning off".
Redis simply serializes every operation, I thought. Transaction = run a Lua script as a single operation. I think that is ACID, if you count RAM as "durable" and doing one thing at a time as "concurrent".
Yeah, I think they were talking about distributed transactions, Redis only support transaction in a single instance, not in a cluster. You can not run Lua across machines.
Comments
What is license ? I see Download but it is not clear if it is Open Source
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.
Hi,
Having Open Source Project on GitHub does not mean you need to become less agile. First there will not be instantly 1000 of people sending you pull requests, second even if they do - you have no obligation to take them in.
However if you say, we can write crap code... and no one would know because they only see binaries, this is not really a way gain a good confidence
In my opinion those days just having a "binary you can use" is the worst way to go for something like database/data store. If you are not sure about your Open Source plans having something like SaaS solution with free tier so users can experiment easily could be way to go
Thank you for the suggestions. We are currently developing a cloud-native version of EloqKV, with both Serverless and BYOC (Bring Your Own Cloud) options underway. The binary is a technology preview for those interested in experiencing the new architecture. EloqKV is built with a cloud-native focus, featuring a quaternary decoupling architecture that enables independent scaling of CPU, memory, storage, and logging. This design maximizes cloud elasticity for optimal scalability and resource efficiency. So I completely agree with the suggestion to offer a SaaS solution, allowing users to experiment.
AGPL is open source but also seems to defend against large companies and cloud providers using without paying for a license. With a contributor agreement in place you can sell a different license to them.
DB sales of open source are based on cloud and security. You can keep some security as open core along with cloud deployment.
Open source is about expanding the total potential market even if you only capture a portion of the value there.
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.
If it's not open-sourced, I’m not going to use it to store my critical data. Just saying...
I second this. It's too risky and simply not worth it. Nevertheless, I find this "optional ACID" thing interesting. Many years ago when I was a graduate student, NoSQL was a big thing. It was widely claimed that transactions were expensive and you had to drop them in exchange to scale. I always had this question that if transactions were the culprit, why not turning them off? I later found that the relational system is such a monolith that everything (caching, concurrency control, logging, locking) is wired together in an extremely complex way and there is simply no "turning off".
Redis simply serializes every operation, I thought. Transaction = run a Lua script as a single operation. I think that is ACID, if you count RAM as "durable" and doing one thing at a time as "concurrent".
Yeah, I think they were talking about distributed transactions, Redis only support transaction in a single instance, not in a cluster. You can not run Lua across machines.
https://yourdatafitsinram.net h/t daemonology ;)