# Table of Contents - [Installation | DiceDB](#installation-dicedb) - [Hello, World - Simple | DiceDB](#hello-world-simple-dicedb) - [EXISTS | DiceDB](#exists-dicedb) - [Hello, World - Reactive | DiceDB](#hello-world-reactive-dicedb) - [DiceDB - an open-source, fast, reactive, in-memory database optimized for modern hardware.](#dicedb-an-open-source-fast-reactive-in-memory-database-optimized-for-modern-hardware-) - [Go | DiceDB](#go-dicedb) - [EXPIREAT | DiceDB](#expireat-dicedb) - [EXPIRE | DiceDB](#expire-dicedb) - [ECHO | DiceDB](#echo-dicedb) - [EXPIRETIME | DiceDB](#expiretime-dicedb) - [DECR | DiceDB](#decr-dicedb) - [DECRBY | DiceDB](#decrby-dicedb) - [DEL | DiceDB](#del-dicedb) - [GET | DiceDB](#get-dicedb) - [GET.WATCH | DiceDB](#get-watch-dicedb) - [FLUSHDB | DiceDB](#flushdb-dicedb) - [GETDEL | DiceDB](#getdel-dicedb) - [HANDSHAKE | DiceDB](#handshake-dicedb) - [HSET | DiceDB](#hset-dicedb) - [GETEX | DiceDB](#getex-dicedb) - [HGETALL.WATCH | DiceDB](#hgetall-watch-dicedb) - [HGETALL | DiceDB](#hgetall-dicedb) - [INCR | DiceDB](#incr-dicedb) - [HGET | DiceDB](#hget-dicedb) - [PING | DiceDB](#ping-dicedb) - [INCRBY | DiceDB](#incrby-dicedb) - [SET | DiceDB](#set-dicedb) - [TTL | DiceDB](#ttl-dicedb) - [TYPE | DiceDB](#type-dicedb) - [UNWATCH | DiceDB](#unwatch-dicedb) - [DiceDB Roadmap](#dicedb-roadmap) - [DiceDB Benchmarks](#dicedb-benchmarks) - [Reactivity in DiceDB](#reactivity-in-dicedb) - [404 | DiceDB](#404-dicedb) --- # Installation | DiceDB Installation ============ ### What is DiceDB? DiceDB is an open-source, fast, reactive, in-memory database optimized for modern hardware. Commonly used as a cache, it offers a familiar interface while enabling real-time data updates through query subscriptions. It delivers higher throughput and lower median latencies, making it ideal for modern workloads. We support multiple ways to install DiceDB, one of which is using Docker and the other is building from source. Both of these methods can be found [here](https://github.com/DiceDB/dice/blob/master/README.md) . To work with DiceDB from a command line interface, you can use the [DiceDB CLI](https://github.com/DiceDB/dicedb-cli) and the installation instructions can be found [here](https://github.com/DiceDB/dicedb-cli/blob/master/README.md) . Once everything is installed, you are all set for a [Hello, World example](/get-started/hello-world/) . --- # Hello, World - Simple | DiceDB Hello, World - Simple ===================== Before we start with Hello, World program for DiceDB, make sure you have 1. a running instance of DiceDB 2. installed [DiceDB CLI](https://github.com/dicedb/dicedb-cli) You can follow the steps mentioned in the [installation](/get-started/installation/) guide to wrap up the installation. Starting DiceDB --------------- Once the DiceDB server starts, you will see output similar to this ██████╗ ██╗ ██████╗███████╗██████╗ ██████╗ ██╔══██╗██║██╔════╝██╔════╝██╔══██╗██╔══██╗ ██║ ██║██║██║ █████╗ ██║ ██║██████╔╝ ██║ ██║██║██║ ██╔══╝ ██║ ██║██╔══██╗ ██████╔╝██║╚██████╗███████╗██████╔╝██████╔╝ ╚═════╝ ╚═╝ ╚═════╝╚══════╝╚═════╝ ╚═════╝ 2025-02-17T07:15:33Z INF starting DiceDB version=0.1.02025-02-17T07:15:33Z INF running with total_commands=212025-02-17T07:15:33Z INF running with engine=ironhawk2025-02-17T07:15:33Z INF running with port=73792025-02-17T07:15:33Z INF running on cores=162025-02-17T07:15:33Z INF running with shards=16 Starting the DiceDB CLI ----------------------- DiceDB CLI is your portal to all things DiceDB, and once you start you will get a REPL to interact with the database and it looks something like this localhost:7379> This indicates that you’re connected to the default DiceDB instance on your local machine on port 7379. A simple Set-Get Example ------------------------ DiceDB is a KV store and one of the most basic operations is to store a key and a value and then retrieve it. To store `` in DiceDB, we use the [`SET`](/commands/set) command and then retrieve it using the [`GET`](/commands/get) command. localhost:7379> SET k1 v1OK OKlocalhost:7379> GET k1OK v1 Here’s a breakdown of what happened, * `SET`: This is the DiceDB command to store a value * `k1`: This is the key we’re assigning to the value * `v1`: This is the actual value we want to store. It’s a simple string in this case * `OK`: DiceDB’s response indicating successful storage Note: The first `OK` is the status of the command, while the second `OK` is the output of the command. ### Bottom Line This is just the tip of the iceberg when it comes to DiceDB. We’ve covered the basics of connecting to a DiceDB instance, storing a simple string, and retrieving it. The true power of DiceDB lies in its ability to intuitively build reactive applications like [chatrooms](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) , handle complex data structures and perform operations efficiently. But all of that after we do our first tutorial for reactivity and query subscriptions. --- # EXISTS | DiceDB EXISTS ====== #### Syntax EXISTS key [key ...] EXISTS command returns the count of keys that exist among the given arguments without modifying them. #### Examples localhost:7379> SET k1 v1OKlocalhost:7379> SET k2 v2OKlocalhost:7379> EXISTS k1 k2 k3OK 2 --- # Hello, World - Reactive | DiceDB Hello, World - Reactive ======================= DiceDB is a [reactive database](/reactivity/) that allows you to create query subscriptions. When you `WATCH` a particular key or command, DiceDB proactively executes the query and sends you the result whenever the data changes. This eliminates the need to poll the database for changes or work with change events. To demonstrate this, here’s a quick “Hello, World!” example. But, before we start, make sure you have complete the [Hello, World!](/get-started/hello-world/) example. Watching a key -------------- To see what reactivity is, let’s watch a key. You need to open three terminal sessions, connect all of them with the same DiceDB server using the DiceDB CLI. In the first _two_ terminal sessions, run the following command to watch the key `k1`. localhost:7379> GET.WATCH k1 In the third terminal session, run the following command to set the value of `k1` to `v1`. localhost:7379> SET k1 v1OK OK In the first two terminal sessions, you will see the following output. localhost:7379> GET.WATCH k1entered the watch mode for GET.WATCH k1OK [fingerprint=2356444921] v1 Now, if you set the value of `k1` to `v2`, you will see the following output in the first two terminal sessions. localhost:7379> GET.WATCH k1entered the watch mode for GET.WATCH k1OK [fingerprint=2356444921] v1OK [fingerprint=2356444921] v2 This is the reactivity in action. Here you are watching the key `k1` and getting notified whenever the value of `k1` changes, but it is not just a change event, but the actual result set. This makes it really powerful and flexible to build real-time applications. > Note: In CLI, you can watch one command at a time, but programmatically you can watch multiple commands at the same time and handle them in parallel. You can take a look at our [Chatroom](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) > to see how to do that. What else can I watch? ---------------------- Any readonly command will have a `.WATCH` version that allows you to watch the result of the command. This is a simple convention that we follow to make it easier to understand what is being watched. > we are in process of implementing the `.WATCH` commands for all query commands in DiceDB, but today we support [`GET.WATCH`](/commands/getwatch) > , etc. You can find them in the commands section. With subsequent releases, we will keep shipping `.WATCH` commands for all the query commands in DiceDB. --- # DiceDB - an open-source, fast, reactive, in-memory database optimized for modern hardware. DiceDB; ======= * is [reactive](/get-started/hello-world-reactive/) with query subscriptions * is [fast](/benchmarks) and optimized for modern hardware * is [familiar](/commands/get/) and easy to use * is [open source](https://github.com/DiceDB/dice/blob/master/LICENSE) [**Get Started →**](/get-started/installation/) [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") [Docs](/commands/get/ "DiceDB documentation") We are gearing up for our next big release, here's our [roadmap](/roadmap) . [Play](https://youtube.com/watch?v=1hGwZ-IeN6M) ### Reactive instead of polling the database for changes, DiceDB can push the resultset if you subscribe to it. ### Fast higher throughput and lower median latencies, making it ideal for modern workloads. ### For Modern Hardware fully utilizes underlying cores to get higher throughput and better hardware utilization. Performance Benchmarks ---------------------- On a Hetzner CCX23 machine with 4 vCPU and 16GB RAM here are our numbers around throughput and GET/SET latencies when compared with other in-memory databases for \`num\_clients = 4\`. | Metric | DiceDB | Redis | | -------------------- | -------- | -------- | | Throughput (ops/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 | \-> detailed [benchmark numbers](/benchmarks) and ways to reproduce them. DiceDB is proudly open-source ----------------------------- DiceDB and all of its dependent packages, libraries, and modules are open-sourced under the [BSD 3-Clause License](https://github.com/dicedb/dice/blob/master/LICENSE) . We're building DiceDB to be a fast, reactive, in-memory database that is easy to use and deploy. We're open-sourcing it to allow the community to contribute and make it better. [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") [Join Discord](https://discord.gg/6r8uXWtXh7 "Join DiceDB's Discord Server") [Follow on Twitter](https://twitter.com/TheDiceDB "Follow DiceDB on Twitter") Like what we do?, support us! ----------------------------- DiceDB is a project with a very strong vision and [roadmap](/roadmap) . If you like what we do and find DiceDB useful, please consider supporting us. [Sponsor us on GitHub](https://github.com/sponsors/arpitbbhayani "Sponsor us on GitHub") [Our roadmap](/roadmap "Our roadmap") DiceDB [Get Started →](/get-started/installation) [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") Developers [Quickstart](/get-started/installation) [Commands](/commands/get) [Roadmap](/roadmap) Examples [CLI Chatroom](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) Us and Socials [Contact Us](mailto:arpit@dicedb.io) [Sponsor Us](https://github.com/sponsors/arpitbbhayani) [](https://twitter.com/thedicedb "Follow DiceDB on X / Twitter") [](https://github.com/dicedb/dice "DiceDB Source Code on GitHub") * © DiceDB, 2025 --- # Go | DiceDB Go == The [DiceDB Go SDK](https://github.com/dicedb/dicedb-go) is the official Go client for DiceDB. > Make sure that the DiceDB server is running before you start using the SDK and following this guide. Installation ------------ To install the DiceDB Go SDK, use `go get`: go get github.com/dicedb/dicedb-go@v1.0.3 Hello World ----------- A simple “Hello, World!” example to get you started with the DiceDB Go SDK, can be found in the [examples/hello-world-go](https://github.com/dicedb/dice/tree/master/examples/hello-world-go) directory. Follow the instructions in the README to run the example. --- # EXPIREAT | DiceDB EXPIREAT ======== #### Syntax EXPIREAT key timestamp [NX | XX | GT | LT] EXPIREAT sets the expiration time of a key as an absolute Unix timestamp (in seconds). After the expiry time has elapsed, the key will be automatically deleted. The command returns 1 if the expiry was set or updated, and 0 if the expiration time was not changed. The command supports the following options: * NX: Set the expiration only if the key does not already have an expiration time. * XX: Set the expiration only if the key already has an expiration time. * GT: Set the expiration only if the key already has an expiration time and the new expiration time is greater than the current expiration time. * LT: Set the expiration only if the key already has an expiration time and the new expiration time is less than the current expiration time. #### Examples locahost:7379> SET k1 v1OK OKlocahost:7379> EXPIREAT k1 1740829942OK 1locahost:7379> EXPIREAT k1 1740829942 NXOK 0locahost:7379> EXPIREAT k1 1740829942 XXOK 0locahost:7379> EXPIREAT k1 1740829943 GTOK 0locahost:7379> EXPIREAT k1 1740829942 LTOK 1 --- # EXPIRE | DiceDB EXPIRE ====== #### Syntax EXPIRE key seconds [NX | XX] EXPIRE sets an expiry (in seconds) on a specified key. After the expiry time has elapsed, the key will be automatically deleted. > If you want to delete the expirtation time on the key, you can use the PERSIST command. The command returns 1 if the expiry was set, and 0 if the key already had an expiry set. The command supports the following options: * NX: Set the expiration only if the key does not already have an expiration time. * XX: Set the expiration only if the key already has an expiration time. #### Examples locahost:7379> SET k1 v1OK OKlocahost:7379> EXPIRE k1 10OK 1locahost:7379> SET k2 v2OK OKlocahost:7379> EXPIRE k2 10 NXOK 1locahost:7379> EXPIRE k2 20 XXOK 1locahost:7379> EXPIRE k2 20 NXOK 0 --- # ECHO | DiceDB ECHO ==== #### Syntax ECHO message ECHO command returns the message passed to it. #### Examples localhost:7379> ECHO hello!OK hello! --- # EXPIRETIME | DiceDB EXPIRETIME ========== #### Syntax EXPIRETIME key EXPIRETIME returns the absolute Unix timestamp in seconds at which the given key will expire. The command returns -1 if the key exists but has no associated expiration time. The command returns -2 if the key does not exist. #### Examples locahost:7379> SET k1 v1OK OKlocahost:7379> EXPIRE k1 10OK 1locahost:7379> EXPIRETIME k1OK 1740829178 --- # DECR | DiceDB DECR ==== #### Syntax DECR key DECR command decrements the integer at ‘key’ by one. Creates ‘key’ as -1 if absent. Errors on wrong type or non-integer string. Limited to 64-bit signed integers. Returns the new value of ‘key’ on success. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> DECR kOK 42 --- # DECRBY | DiceDB DECRBY ====== #### Syntax DECRBY key delta DECRBY command decrements the integer at ‘key’ by the delta specified. Creates ‘key’ with value (-delta) if absent. Errors on wrong type or non-integer string. Limited to 64-bit signed integers. Returns the new value of ‘key’ on success. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> DECRBY k 10OK 33 --- # DEL | DiceDB DEL === #### Syntax DEL key [key ...] DEL command deletes all the specified keys and returns the number of keys deleted on success. #### Examples localhost:7379> SET k1 v1OK OKlocalhost:7379> SET k2 v2OK OKlocalhost:7379> DEL k1 k2 k3OK 2 --- # GET | DiceDB GET === #### Syntax GET key GET returns the value for the key in args. The command returns (nil) if the key does not exist. #### Examples localhost:7379> SET k1 v1OK OKlocalhost:7379> GET k1OK v1localhost:7379> GET k2(nil) --- # GET.WATCH | DiceDB GET.WATCH ========= #### Syntax GET.WATCH key GET.WATCH creates a query subscription over the GET command. The client invoking the command will receive the output of the GET command (not just the notification) whenever the value against the key is updated. You can update the key in any other client. The GET.WATCH client will receive the updated value. #### Examples client1:7379> SET k1 v1OK OKclient1:7379> GET.WATCH k1entered the watch mode for GET.WATCH k1 client2:7379> SET k1 v2OK OK client1:7379> ...entered the watch mode for GET.WATCH k1OK [fingerprint=2356444921] v2 --- # FLUSHDB | DiceDB FLUSHDB ======= #### Syntax FLUSHDB FLUSHDB deletes all keys present in the database. #### Examples locahost:7379> SET k1 v1OK OKlocahost:7379> SET k2 v2OK OKlocahost:7379> FLUSHDBOK OKlocalhost:7379> GET k1OK (nil)localhost:7379> GET k2OK (nil) --- # GETDEL | DiceDB GETDEL ====== #### Syntax GETDEL key GETDEL returns the value of the key and then deletes the key. The command returns (nil) if the key does not exist. #### Examples localhost:7379> SET k vOK OKlocalhost:7379> GETDEL kOK vlocalhost:7379> GET k(nil) --- # HANDSHAKE | DiceDB HANDSHAKE ========= #### Syntax HANDSHAKE client_id execution_mode HANDSHAKE is used to tell the DiceDB server the purpose of the connection. It registers the client\_id and execution\_mode. The client\_id is a unique identifier for the client. It can be any string, typically a UUID. The execution\_mode is the mode of the connection, it can be one of the following: 1. “command” - The client will send commands to the server and receive responses. 2. “watch” - The connection in the watch mode will be used to receive the responses of query subscriptions. If you use DiceDB SDK or CLI then this HANDSHAKE command is automatically sent when the connection is established or when you establish a subscription. #### Examples localhost:7379> HANDSHAKE 4c9d0411-6b28-4ee5-b78a-e7e258afa52f commandOK OK --- # HSET | DiceDB HSET ==== #### Syntax HSET key field value [field value ...] HSET sets the field and value for the key in the string-string map. Returns “OK” if the field value was set or updated in the map. Returns (nil) if the field value was not set or updated. #### Examples localhost:7379> HSET k1 f1 v1OK 1localhost:7379> HSET k1 f1 v1 f2 v2 f3 v3OK 2localhost:7379> HGET k1 f1OK v1localhost:7379> HGET k2 f1OK (nil) --- # GETEX | DiceDB GETEX ===== #### Syntax GETEX key [EX seconds] [PX milliseconds] [EXAT timestamp-seconds] [PXAT timestamp-milliseconds] [PERSIST] GETEX gets the value of key and optionally set its expiration. The behavior of the command is similar to the GET command with the addition of the ability to set an expiration on the key. The command returns (nil) if the key does not exist. The command supports the following options: * EX seconds: Set the expiration to seconds from now. * PX milliseconds: Set the expiration to milliseconds from now. * EXAT timestamp: Set the expiration to a Unix timestamp. * PXAT timestamp: Set the expiration to a Unix timestamp in milliseconds. * PERSIST: Remove the expiration from the key. #### Examples localhost:7379> SET k vOK OKlocalhost:7379> GETEX k EX 1000OK vlocalhost:7379> TTL kOK 996localhost:7379> GETEX k PX 200000OK vlocalhost:7379> GETEX k EXAT 1772377267OK vlocalhost:7379> GETEX k PXAT 1772377267000OK vlocalhost:7379> GETEX k PERSISTOK vlocalhost:7379> GET k(nil) --- # HGETALL.WATCH | DiceDB HGETALL.WATCH ============= #### Syntax HGETALL.WATCH key HGETALL.WATCH creates a query subscription over the HGETALL command. The client invoking the command will receive the output of the HGETALL command (not just the notification) whenever the value against the key is updated. You can update the key in any other client. The HGETALL.WATCH client will receive the updated value. #### Examples client1:7379> HSET k f1 v1OK 1client1:7379> HGETALL.WATCH kentered the watch mode for HGETALL.WATCH k client2:7379> HSET k f2 v2OK 1 client1:7379> ...entered the watch mode for HGETALL.WATCH kOK [fingerprint=4237011426]f1=v1f2=v2 --- # HGETALL | DiceDB HGETALL ======= #### Syntax HGETALL key HGETALL returns all the field-value pairs for the key from the string-string map. The command returns (nil) if the key does not exist or the map is empty. #### Examples localhost:7379> HSET k1 f1 v1 f2 v2 f3 v3OK 3localhost:7379> HGETALL k1OKf1=v1f2=v2f3=v3localhost:7379> HGETALL k2OK (nil) --- # INCR | DiceDB INCR ==== #### Syntax INCR key INCR command increments the integer at ‘key’ by one. Creates ‘key’ as 1 if absent. Errors on wrong type or non-integer string. Limited to 64-bit signed integers. Returns the new value of ‘key’ on success. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> INCR kOK 44 --- # HGET | DiceDB HGET ==== #### Syntax HGET key field HGET returns the value of field present in the string-string map held at key. The command returns (nil) if the key or field does not exist. #### Examples localhost:7379> HSET k1 f1 v1OK 1localhost:7379> HGET k1 f1OK v1localhost:7379> HGET k2 f1OK (nil)localhost:7379> HGET k1 f2OK (nil) --- # PING | DiceDB PING ==== #### Syntax PING PING returns PONG if no argument is provided, otherwise it returns PONG with the message argument. #### Examples localhost:7379> PINGPONGlocalhost:7379> PING HelloPONG Hello --- # INCRBY | DiceDB INCRBY ====== #### Syntax INCRBY key delta INCRBY command increments the integer at ‘key’ by the delta specified. Creates ‘key’ with value (delta) if absent. Errors on wrong type or non-integer string. Limited to 64-bit signed integers. Returns the new value of ‘key’ on success. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> INCRBY k 10OK 53 --- # SET | DiceDB SET === #### Syntax SET key value [EX seconds] [PX milliseconds] [EXAT timestamp] [PXAT timestamp] [XX] [NX] [KEEPTTL] SET puts or updates an existing pair. SET identifies the type of the value based on the value itself. If the value is an integer, it will be stored as an integer. Otherwise, it will be stored as a string. * EX seconds: Set the expiration time in seconds * PX milliseconds: Set the expiration time in milliseconds * EXAT timestamp: Set the expiration time in seconds since epoch * PXAT timestamp: Set the expiration time in milliseconds since epoch * XX: Only set the key if it already exists * NX: Only set the key if it does not already exist * KEEPTTL: Keep the existing TTL of the key * GET: Return the value of the key after setting it Returns “OK” if the key was set or updated. Returns (nil) if the key was not set or updated. Returns the value of the key if the GET option is provided. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> SET k 43 EX 10OK OKlocalhost:7379> SET k 43 PX 10000OK OKlocalhost:7379> SET k 43 EXAT 1772377267OK OKlocalhost:7379> SET k 43 PXAT 1772377267000OK OKlocalhost:7379> SET k 43 XXOK OKlocalhost:7379> SET k 43 NXOK (nil)localhost:7379> SET k 43 KEEPTTLOK OKlocalhost:7379> SET k 43 GETOK 43 --- # TTL | DiceDB TTL === #### Syntax TTL key TTL returns the remaining time to live (in seconds) of a key that has an expiration set. * Returns -1 if the key has no expiration. * Returns -2 if the key does not exist. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> TTL kOK -1localhost:7379> SET k 43 EX 10OK OKlocalhost:7379> TTL kOK 9localhost:7379> TTL knOK -2 --- # TYPE | DiceDB TYPE ==== #### Syntax TYPE key TYPE returns the type of the value stored at a specified key. The type can be one of the following: * string * int Returns “none” if the key does not exist. #### Examples localhost:7379> SET k 43OK OKlocalhost:7379> TYPE kintlocalhost:7379> TYPE knnone --- # UNWATCH | DiceDB UNWATCH ======= #### Syntax UNWATCH WATCH command creates a subscription to the key and returns a fingerprint. Use this fingerprint to UNWATCH the subscription. After running the UNWATCH command, the subscription will be removed and the data changes will no longer be sent to the client. Note: If you are using the DiceDB CLI, then you need not run this command given the REPL will implicitly run this command when you exit the watch mode. #### Examples localhost:7379> UNWATCH 2356444921 --- # DiceDB Roadmap Roadmap ======= We track DiceDB’s Roadmap in a simple [Google Spreadsheet](https://docs.google.com/spreadsheets/d/1bcf-NOVcKESG4L0QL8jhZuetIeDTzoVngf-0HbzIdO8/edit?usp=sharing) . DiceDB [Get Started →](/get-started/installation) [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") Developers [Quickstart](/get-started/installation) [Commands](/commands/get) [Roadmap](/roadmap) Examples [CLI Chatroom](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) Us and Socials [Contact Us](mailto:arpit@dicedb.io) [Sponsor Us](https://github.com/sponsors/arpitbbhayani) [](https://twitter.com/thedicedb "Follow DiceDB on X / Twitter") [](https://github.com/dicedb/dice "DiceDB Source Code on GitHub") * © DiceDB, 2025 --- # DiceDB Benchmarks Benchmarks ========== > Last updated: 8th March, 2025 We benchmarked DiceDB using our [membench](https://github.com/DiceDB/membench) benchmark utility with various configurations and various machine types, here are the details Results Observed ---------------- On a Hetzner CCX13 machine with 2 vCPU and 8GB RAM here are our numbers around throughput and GET/SET latencies. | num-clients | Throughput (ops/sec) | GET p50 (ms) | GET p90 (ms) | SET p50 (ms) | SET p90 (ms) | | --- | --- | --- | --- | --- | --- | | 1 | 3159 | 0.288767 | 0.354303 | 0.294911 | 0.364543 | | 2 | 5415 | 0.325631 | 0.473087 | 0.327679 | 0.473087 | | 4 | 9628 | 0.309247 | 0.518143 | 0.315391 | 0.528383 | | 8 | 13030 | 0.344063 | 0.757759 | 0.350207 | 0.765951 | On a Hetzner CCX23 machine with 4 vCPU and 16GB RAM here are our numbers around throughput and GET/SET latencies. | num-clients | Throughput (ops/sec) | GET p50 (ms) | GET p90 (ms) | SET p50 (ms) | SET p90 (ms) | | --- | --- | --- | --- | --- | --- | | 1 | 3694 | 0.258047 | 0.309247 | 0.264191 | 0.315391 | | 2 | 7310 | 0.251903 | 0.323583 | 0.254975 | 0.325631 | | 4 | 15655 | 0.227327 | 0.337919 | 0.230399 | 0.339967 | | 8 | 26459 | 0.248831 | 0.475135 | 0.250879 | 0.483327 | ### Comparing with other in-mem databases On a Hetzner CCX23 machine with 4 vCPU and 16GB RAM here are our numbers around throughput and GET/SET latencies when compared with other in-memory databases for `num_clients = 4`. | Metric | DiceDB | Redis | | --- | --- | --- | | Throughput (ops/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 | Execution Configuration ----------------------- We ran DiceDB with default configuration on one VM and membench on another. $ ./dicedb ██████╗ ██╗ ██████╗███████╗██████╗ ██████╗ ██╔══██╗██║██╔════╝██╔════╝██╔══██╗██╔══██╗ ██║ ██║██║██║ █████╗ ██║ ██║██████╔╝ ██║ ██║██║██║ ██╔══╝ ██║ ██║██╔══██╗ ██████╔╝██║╚██████╗███████╗██████╔╝██████╔╝ ╚═════╝ ╚═╝ ╚═════╝╚══════╝╚═════╝ ╚═════╝ 2025-03-09T16:46:03+05:30 INF starting DiceDB version=0.1.02025-03-09T16:46:03+05:30 INF running with total_commands=212025-03-09T16:46:03+05:30 INF running with engine=ironhawk2025-03-09T16:46:03+05:30 INF running with port=73792025-03-09T16:46:03+05:30 INF running on cores=42025-03-09T16:46:03+05:30 INF running with shards=4 [membench](https://github.com/DiceDB/membench) was run with the following configuration. The following command creates a load of `num-clients` concurrent clients creating one connection each on `dicedb` (running on `host` and `port`). Each client fires `num-requests` operations on the database. $ ./membench benchmark \ --database dicedb \ --host xx.xx.xx.xx \ --port 7379 \ --num-requests 100000 \ --num-clients 4 We iterated `num_clients` and underlying DiceDB VM and the numbers are as shown above. DiceDB [Get Started →](/get-started/installation) [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") Developers [Quickstart](/get-started/installation) [Commands](/commands/get) [Roadmap](/roadmap) Examples [CLI Chatroom](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) Us and Socials [Contact Us](mailto:arpit@dicedb.io) [Sponsor Us](https://github.com/sponsors/arpitbbhayani) [](https://twitter.com/thedicedb "Follow DiceDB on X / Twitter") [](https://github.com/dicedb/dice "DiceDB Source Code on GitHub") * © DiceDB, 2025 --- # Reactivity in DiceDB Reactivity ========== In traditional databases, we query data when it’s needed. This is a classic process but it can become highly inefficient when large number of expensive and redundant queries are frequently fired on the database. * expensive: query takes a relatively longer time to execute * redundant: large number of same query is fired on the database Leaderboard ----------- Imagine a traditional database that maintains a leaderboard for a competitive game. Here, an asynchronous flow updates the leaderboard data continuously in the database, reflecting new scores or rankings as they come in. ![naive-leaderboard](https://github.com/user-attachments/assets/afeb35c5-c005-4435-ac9b-d681d9993444) Now consider the users, thousands of clients query this leaderboard every 10 seconds to get the latest rankings. Every query requires the database to compute the current leaderboard standings based on the updated data and then respond to the client with the latest results. Upon receiving the result, each client proceeds to render the leaderboard in its application, ensuring users see the current standings. There are several issues in this setup, 1. Redundant Computation: Since thousands of clients are querying the database every few seconds, the database repeatedly computes the leaderboard, even if there has been little or no change in scores. This results in substantial redundant processing, significantly taxing the database resources. 2. High Load and Latency: The high frequency and volume of queries introduce a considerable load on the database, leading to slower response times. 3. Increased Infrastructure Costs: To handle the high query volume, the system may require powerful hardware and extensive scaling strategies, leading to increased operational costs. This traditional query model is inefficient for high-read, rapidly updating data structures like leaderboards, where many clients want real-time information. This setup incurs significant resource overhead and diminishes the overall system performance, especially under heavy load. This is where a reactive database chimes in and shines. What is a reactive database? ---------------------------- A reactive database pushes updated query results to clients as soon as the underlying data changes. DiceDB, upon detecting the change in data, automatically re-evaluates the relevant queries and immediately streams the updated result sets to all clients who have subscribed to it. ![reactive leaderboard](https://github.com/user-attachments/assets/08ab40ab-3a34-4d74-9b2f-7d21bbeef73c) This real-time reactivity ensures that clients always receive the latest data without the need to send repeated queries, dramatically reducing network load, database load, and latency while providing an efficient, seamless experience for data-driven applications. DiceDB, a reactive database --------------------------- DiceDB exemplifies the reactive database model and also focuses on real-time reactivity and efficiency. In DiceDB, clients can set up query subscriptions for specific keys and queries and when a value tied to a subscribed query changes, the updated result set is pushed directly to the subscribed clients. This push model eliminates the need for clients to continuously poll for updates. ### Creating a query subscription DiceDB makes creating query subscriptions straightforward. For all read-only commands, such as `GET` and `ZRANGE`, DiceDB introduces a `.WATCH` variant, enabling reactive capabilities: * [GET.WATCH](/commands/getwatch) * [ZRANGE.WATCH](/commands/zrangewatch) The `.WATCH` variant signifies a query subscription. For example: * Executing `GET k1` simply retrieves the value associated with the key, say `v1`. * Executing `GET.WATCH k1` establishes a query subscription. Whenever the data changes (e.g., `v1` updates to `v2`), DiceDB automatically evaluates the query and streams the updated result (`v2`) over the same database connection. This makes DiceDB super powerful for building real-time reactive applications. Support for `.WATCH` will soon extend to additional read-only commands, unlocking more reactive use cases. ### But, isn’t it same as CDC No, DiceDB is not the same as CDC. While CDC captures and streams data changes as deltas, DiceDB streams the evaluated output of a query whenever the underlying data changes. This goes beyond mere change notifications, making DiceDB a truly real-time reactive database. Efficiency Gains and Cost Reduction ----------------------------------- DiceDB’s reactivity model delivers tangible benefits: * **Reduced Query Load**: Shifting from client polling to server push eliminates redundant queries, particularly in high-read scenarios with multiple clients requesting the same data. * **Lower Latency**: Updates are pushed instantly upon data changes, ensuring clients receive real-time information with minimal delay, enhancing user experience. * **Resource Savings**: By processing queries once and streaming results to all subscribers, DiceDB optimizes CPU, memory, and network usage, reducing infrastructure requirements and lowering operational costs. In conclusion ------------- Traditional polling-based systems struggle to efficiently deliver real-time data at scale, often incurring high costs, latency, and redundant computations. DiceDB’s reactive approach revolutionizes this by pushing updated query results directly to clients as data changes, eliminating inefficiencies while enhancing performance. For applications demanding real-time responsiveness, like leaderboards, DiceDB offers a seamless, cost-effective solution tailored for the modern era of reactive computing. DiceDB [Get Started →](/get-started/installation) [GitHub 9.6k+](https://github.com/dicedb/dice "DiceDB source code on GitHub") Developers [Quickstart](/get-started/installation) [Commands](/commands/get) [Roadmap](/roadmap) Examples [CLI Chatroom](https://github.com/DiceDB/dice/tree/master/examples/chatroom-go) Us and Socials [Contact Us](mailto:arpit@dicedb.io) [Sponsor Us](https://github.com/sponsors/arpitbbhayani) [](https://twitter.com/thedicedb "Follow DiceDB on X / Twitter") [](https://github.com/dicedb/dice "DiceDB Source Code on GitHub") * © DiceDB, 2025 --- # 404 | DiceDB 404 === Page not found. Check the URL or try using the search bar. ---