You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Redka aims to reimplement the core parts of Redis with SQLite, while remaining compatible with Redis API.
3
+
Redka aims to reimplement the core parts of Redis with SQL, while remaining compatible with Redis API.
4
4
5
5
Notable features:
6
6
7
-
- Data does not have to fit in RAM.
8
-
- ACID transactions.
9
-
- SQL views for better introspection and reporting.
10
-
- Both in-process (Go API) and standalone (RESP) servers.
11
-
- Redis-compatible commands and wire protocol.
7
+
- Data doesn't have to fit in RAM.
8
+
- Supports ACID transactions.
9
+
- SQL views for easier analysis and reporting.
10
+
- Works with both SQLite and PostgreSQL (coming v0.6.0) backends.
11
+
- Runs in-process (Go API) or as a standalone server.
12
+
- Redis-compatible commands and wire protocol (RESP).
12
13
13
14
Redka is [functionally ready](docs/roadmap.md) for 1.0. Feel free to try it in non-critical production scenarios and provide feedback in the issues.
14
15
16
+
## Use cases
17
+
18
+
Here are some situations where Redka might be helpful:
19
+
20
+
_Embedded cache for Go applications_. If your Go app already uses SQLite or just needs a simple, built-in key-value store, Redka is a natural fit. It gives you Redis-like features without the hassle of running a separate server. The cache persists across application restarts, and backup is as easy as copying a file.
21
+
22
+
_Lightweight testing environment_. Your app uses Redis in production, but setting up a Redis server for local development or integration tests can be a hassle. Redka, when used with an in-memory SQLite database, gives you a fast alternative with complete isolation for each test run.
23
+
24
+
_Postgres-first data structures_. If you prefer to use PostgreSQL for everything but need Redis-like data structures (like lists and sorted sets), Redka can use your existing database as the backend. This way, you can manage both relational data and specialized data structures with the same tools and transactional guarantees.
- Go module for in-process use: [installation](docs/install-module.md), [usage](docs/usage-module.md).
33
44
45
+
## Storage
46
+
47
+
Redka can use either SQLite or PostgreSQL as its backend. It stores data in a [SQL database](docs/persistence.md) with a simple schema and provides views for better introspection.
48
+
34
49
## Performance
35
50
36
-
According to the [benchmarks](docs/performance.md), Redka is several times slower than Redis. Still, it can do up to 100K op/sec on a Macbook Air, which is pretty good if you ask me (and probably 10x more than most applications will ever need).
51
+
Redka is not about raw performance. You can't beat a specialized data store like Redis with a general-purpose relational backend like SQLite. However, Redka can still handle tens of thousands of operations per second, which should be more than enough for many apps.
37
52
38
-
Redka stores data in a [SQLite database](docs/persistence.md)with a simple schema and provides views for better introspection.
53
+
See the [benchmarks](docs/performance.md) for more details.
39
54
40
55
## Contributing
41
56
42
57
Contributions are welcome. For anything other than bugfixes, please first open an issue to discuss what you want to change.
GET: 103092.78 requests per second, p50=0.063 msec
50
40
```
51
41
52
-
So while Redka is 2-5 times slower than Redis (not surprising, since we are comparing a relational database to a key-value data store), it can still do 26K writes/sec and 94K reads/sec, which is pretty good if you ask me.
So while Redka is noticeably slower than Redis (not surprising, since we are comparing a relational database to a key-value data store), it can still handle tens of thousands of operations per second. That should be more than enough for many apps.
0 commit comments