📚 EchoVault - Awesome Go Library for Database

Go Gopher mascot for EchoVault

Embeddable Distributed in-memory data store compatible with Redis clients.

🏷️ Database
📂 Data stores with expiring records, in-memory distributed data stores, or in-memory subsets of file-based databases.
⭐ 393 stars
View on GitHub 🔗

Detailed Description of EchoVault

Go Go Report Card codecov
Go Reference GitHub Release License
Mentioned in Awesome Go Discord

Table of Contents

  1. What is SugarDB
  2. Features
  3. Usage (Embedded)
  4. Usage (Client-Server)
    1. Homebrew
    2. Docker
    3. GitHub Container Registry
    4. Binaries
  5. Clients
  6. Benchmarks
  7. Commands
    1. ACL
    2. ADMIN
    3. CONNECTION
    4. GENERIC
    5. HASH
    6. LIST
    7. PUBSUB
    8. SET
    9. SORTED SET
    10. STRING

What is SugarDB?

SugarDB is a highly configurable, distributed, in-memory data store and cache implemented in Go. It can be imported as a Go library or run as an independent service.

SugarDB aims to provide a rich set of data structures and functions for manipulating data in memory. These data structures include, but are not limited to: Lists, Sets, Sorted Sets, Hashes, and much more to come soon.

SugarDB provides a persistence layer for increased reliability. Both Append-Only files and snapshots can be used to persist data in the disk for recovery in case of unexpected shutdowns.

Replication is a core feature of SugarDB and is implemented using the RAFT algorithm, allowing you to create a fault-tolerant cluster of SugarDB nodes to improve reliability. If you do not need a replication cluster, you can always run SugarDB in standalone mode and have a fully capable single node.

SugarDB aims to not only be a server but to be importable to existing projects to enhance them with SugarDB features, this capability is always being worked on and improved.

Features

Features offered by SugarDB include:

  1. TLS and mTLS support for multiple server and client RootCAs.
  2. Replication cluster support using the RAFT algorithm.
  3. ACL Layer for user Authentication and Authorization.
  4. Distributed Pub/Sub functionality.
  5. Sets, Sorted Sets, Hashes, Lists and more.
  6. Persistence layer with Snapshots and Append-Only files.
  7. Key Eviction Policies.
  8. Command extension via shared object files.
  9. Command extension via embedded API.
  10. Multi-database support for key namespacing.

We are working hard to add more features to SugarDB to make it much more powerful. Features in the roadmap include:

  1. Sharding
  2. Streams
  3. Transactions
  4. Bitmap
  5. HyperLogLog
  6. Lua Modules
  7. JSON
  8. Improved Observability

Usage (Embedded)

Install SugarDB with: go get github.com/echovault/sugardb.

Here's an example of using SugarDB as an embedded library. You can access all of SugarDB's commands using an ergonomic API.

func main() {
  server, err := sugardb.NewSugarDB()
  if err != nil {
    log.Fatal(err)
  }

  _, _, _ = server.Set("key", "Hello, SugarDB!", sugardb.SETOptions{})

  v, _ := server.Get("key")
  fmt.Println(v) // Hello, SugarDB!

  // (Optional): Listen for TCP connections on this SugarDB instance.
  server.Start()
}

An embedded SugarDB instance can still be part of a cluster, and the changes triggered from the API will be consistent across the cluster.

Usage (Client-Server)

Homebrew

To install via homebrew, run:

  1. brew tap echovault/sugardb
  2. brew install echovault/echovault/sugardb

Once installed, you can run the server with the following command: sugardb --bind-addr=localhost --data-dir="path/to/persistence/directory"

Docker

docker pull echovault/sugardb

The full list of tags can be found here.

Container Registry

docker pull ghcr.io/echovault/sugardb

The full list of tags can be found here.

Binaries

You can download the binaries by clicking on a release tag and downloading the binary for your system.

Clients

SugarDB uses RESP, which makes it compatible with existing Redis clients.

Benchmarks

The following benchmark only applies to the TCP client-server mode.

Hardware: MacBook Pro 14in, M1 chip, 16GB RAM, 8 Cores
Command: redis-benchmark -h localhost -p 7480 -q -t ping,set,get,incr,lpush,rpush,lpop,rpop,sadd,hset,zpopmin,lrange,mset
Result:

PING_INLINE: 89285.71 requests per second, p50=0.247 msec                   
PING_MBULK: 85543.20 requests per second, p50=0.239 msec                   
SET: 65573.77 requests per second, p50=0.455 msec                   
GET: 79176.56 requests per second, p50=0.295 msec                   
INCR: 68870.52 requests per second, p50=0.439 msec                   
LPUSH: 27601.44 requests per second, p50=1.567 msec                   
RPUSH: 61842.92 requests per second, p50=0.519 msec                   
LPOP: 58548.01 requests per second, p50=0.567 msec                   
RPOP: 68681.32 requests per second, p50=0.439 msec                   
SADD: 67613.25 requests per second, p50=0.479 msec                   
HSET: 56561.09 requests per second, p50=0.599 msec                   
ZPOPMIN: 70972.32 requests per second, p50=0.359 msec                   
LPUSH (needed to benchmark LRANGE): 26434.05 requests per second, p50=1.623 msec                   
LRANGE_100 (first 100 elements): 26939.66 requests per second, p50=1.263 msec                   
LRANGE_300 (first 300 elements): 5081.82 requests per second, p50=9.095 msec                    
LRANGE_500 (first 500 elements): 2554.87 requests per second, p50=18.191 msec                   
LRANGE_600 (first 600 elements): 1903.96 requests per second, p50=24.607 msec                   
MSET (10 keys): 56022.41 requests per second, p50=0.463 msec

Supported Commands

ACL

ADMIN

CONNECTION

GENERIC

HASH

LIST

PUBSUB

SET

SORTED SET

STRING

← Back to Database - Data stores with expiring records, in-memory distributed data stores, or in-memory subsets of file-based databases.