11–20 of 70 posts
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
Also, part of the beauty of open source is not trying to conform or constantly compare your project to others. It’s awesome that such diversity exists in project communities and the cross-pollination of ideas resulting from it.
So, is it Jepsen-tested?
I think this has a place. I’ve found myself wanting something similar in the past though found other solutions. It seems you have similar reservations toward Mongo and similar software so it’s unlikely it will follow their path. I remember so many folks jumping on Mongo and hailing it as the holy grail of storage, dumping everything into it without much thought. I also remember many of those same people paying dearly…
So, is it Jepsen-tested?
No not using Jepsen. I've written custom tests in GO running thousands of concurrent client connections on local and remote clusters with multiple nodes and node replicas I test consistency, crisis, recovery, etc. The database hasn't shown me personally any flaws whatsoever. Anyone can go ahead and write their own Jepsen tests if they please.
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
Cursus means course in Latin. The database is distributed by nature. Cluster routes data etc. You can piece it together.
For new products I always recommend the same thing: name your competitors and use cases. Compare them in a table; don't make the user think. Who should and should not use your product? Being in-memory and distributed, I imagine your competitors include Ignite and Hazelcast? I read the title as CursorDB, which would have made a nice DB name.
I get that you need to differentiate your project from others if you want to find adoption, and one way of doing that is to compare it to who you feel are competitors. I do feel that the word “competitor” should rather be “alternative” since I don’t think this or many other projects are trying to compete, but instead just trying to exist in their own way and do their own thing. If someone likes it enough but finds a…
it doesn't really matter what you label those comparisons.
think of it like LLM optimization.
Earlier quoted context omitted.
Cursus means course in Latin. The database is distributed by nature. Cluster routes data etc. You can piece it together.
CouchDB is distributed by nature as well. So why use this over CouchDB.