DiceDB

There are _so many_ bugs in this code.<p>One example among many:<p><a href="https:&#x2F;&#x2F;github.com&#x2F;DiceDB&#x2F;dice&#x2F;blob&#x2F;0e241a9ca253f17b4d364cdf0640a4453400f35e&#x2F;internal&#x2F;id&#x2F;id.go" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;DiceDB&#x2F;dice&#x2F;blob&#x2F;0e241a9ca253f17b4d364cdf...</a> defines func ExpandID, which reads from cycleMap without locking the package-global mutex; and func NextID, which writes to cycleMap under a lock of the package-global mutex. So writes are synchronized, but only between each other, and not with reads, so concurrent calls to ExpandID and NextID would race.<p>This is all fine as a hobby project or whatever, but very far from any kind of production-capable system.

Looking at the diceDB code base, I have few questions regarding its design, I&#x27;m asking this to understand the project&#x27;s goals and design rationale. Anyone feel free to help me understand this.<p>I could be wrong but the primary in-memory storage appears to be a standard Go map with locking. Is this a temporary choice for iterative development, and is there a longer-term plan to adopt a more optimized or custom data structure ?<p>I find the DiceDB&#x27;s reactivity mechanism very intriguing, particularly the &quot;re-execution&quot; of the entire watch command (i.e re-running GET.WATCH mykey on key modification), it&#x27;s an intriguing design choice.<p>From what I understand is the Eval func executes client side commands this seem to be laying foundation for more complex watch command that can be evaluated before sending notifications to clients.<p>But I have the following question.<p>What is the primary motivation behind re-executing the entire command, as opposed to simply notifying clients of a key change (as in Redis Pub&#x2F;Sub or streams)? Is the intent to simplify client-side logic by handling complex key dependencies on the server?<p>Given that re-execution seems computationally expensive, especially with multiple watchers or more complex (hypothetical) watch commands, how are potential performance bottlenecks addressed?<p>How does this &quot;re-execution&quot; approach compare in terms of scalability and consistency to more established methods like server-side logic (e.g., Lua scripts in Redis) or change data capture (CDC) ?<p>Are there plans to support more complex watch commands beyond GET.WATCH (e.g. JSON.GET.WATCH), and how would re-execution scale in those cases?<p>I&#x27;m curious about the trade-offs considered in choosing this design and how it aligns with the project&#x27;s overall goals. Any insights into these design decisions would help me understand its use-cases.<p>Thanks

Is there a single sentence anywhere that describes what it actually is?

Using an instrument of chance to name a data store technology is pretty amusing to me.

DiceDB sounds like the name of a joke database that returns random results.

From the benchmarks on 4vCPU and num_clients=4, the numbers doesn&#x27;t look much different.<p>Reactive looks promising, doesn&#x27;t look much useful in realworld for a cache. For example, a client subscribes for something and the machines goes down, what happens to reactivity?

<p><pre><code> | Metric | DiceDB | Redis | | -------------------- | -------- | -------- | | Throughput (ops&#x2F;sec) | 15655 | 12267 | | GET p50 (ms) | 0.227327 | 0.270335 | | GET p90 (ms) | 0.337919 | 0.329727 | | SET p50 (ms) | 0.230399 | 0.272383 | | SET p90 (ms) | 0.339967 | 0.331775 | </code></pre> <i>UPD Nevermind, I didn&#x27;t have my eyes open. Sorry for the confusion.</i><p>Something I still fail to understand is where you can actually spend 20ms while answering a GET request in a RAM keyvalue storage (unless you implement it in Java).<p>I never gained much experience with existing opensource implementations, but when I was building proprietary solutions at my previous workplace, the in-memory response time was measured in tens-hundreds of microseconds. The lower bound of latency is mostly defined by syscalls so using io_uring should in theory result in even better timings, even though I never got to try it in production.<p>If you read from nvme AND also do the erasure-recovery across 6 nodes (lrc-12-2-2) then yes, you got into tens of milliseconds. But seeing these numbers for a single node RAM DB just doesn&#x27;t make sense and I&#x27;m surprised everyone treats them as normal.<p>Does anyone has experience with low-latency high-throughput opensource keyvalue storages? Any specific implementation to recommend?

In-memory caches (lacking persistence) shouldn&#x27;t be called a database. It&#x27;s not totally incorrect, but it&#x27;s an abuse of terminology. Why is a Python dictionary not an in-memory key-value database?

Any reason to use this over Valkey, which is now faster than Redis and community driven? Genuinely interested.

I didn&#x27;t see it in the docs, but I&#x27;d want to know the delivery semantics of the pubsub before using this in production. I assume best effort &#x2F; at most once? Any retries? In what scenarios will the messages be delivered or fail to be delivered?

This seems orders of magnitude slower than Nubmq which was posted yesterday: <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43371097">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=43371097</a>

What are some example use cases where having the ability for the database to push updates to an application would be helpful (vs. the traditional polling approach)?

15655 ops a second with a Hetzner CCX23 machine with 4 vCPU and 16GB RAM is rather slow for an in-memory database I hate to say it. You can&#x27;t blame that on network latency as for example supermassivedb.com is written in go and achieves magnitudes more, actually x20 and it&#x27;s persisted.. I must investigate the bottlenecks with Dice.

- proudly open source. cool! - join discord. YAY :(

FYI: Here is the creator and maintainer&#x27;s profile: <a href="https:&#x2F;&#x2F;github.com&#x2F;arpitbbhayani" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;arpitbbhayani</a><p>Is there a plan to commercialise this product? (Offer commercial support, features, etc.) I could not find anything obvious from the home page.

Is Arpit is the system design course guy?

I feel like this needs a ‘Why DiceDB instead of Redis or Valtio’ section prominently on the homepage.

I love the &quot;Follow on twitter&quot; link with the old logo and everything, they probably used a template that hasn&#x27;t been updated recently but I&#x27;m choosing to believe it&#x27;s actually a subtle sign of protest or resistance.

Is this suffering from the same problems like Redis when trying to horizontally scale?

&gt; For Modern Hardware fully utilizes underlying core to get higgher throughput and better hardware utilization.<p>Would be great to disclose details of this one. I&#x27;m interested in using what DiceDB achieves higher throughput.

&gt; fully utilizes underlying core to get higgher throughput and better hardware utilization<p>FYI this is a misspelling of &quot;higher&quot;

Who is this for? Can you help me explain why and when I&#x27;d want to use this in place of redis&#x2F;dragonfly

I think Postgres can do everything this does and better if you use LISTEN&#x2F;NOTIFY.

I like it!<p>Anyway to persist data in case of reboots?<p>That&#x27;s the only thing missing here.<p>Is Go the only SDK ?

Why would I use this over keyspace notifications in redis?

Database as a transport?

DiceDB is an in-memory, multi-threaded key-value DBMS that supports the Redis protocol.<p>It’s written in Go.

I think performance benchmark you have done for DiceDB is fake.<p>These are the real numbers - <a href="https:&#x2F;&#x2F;dzone.com&#x2F;articles&#x2F;performance-and-scalability-analysis-of-redis-memcached" rel="nofollow">https:&#x2F;&#x2F;dzone.com&#x2F;articles&#x2F;performance-and-scalability-analy...</a><p>Does not match with your benchmarks.