Redka reimplements the core parts of Redis in SQL while staying compatible with the Redis API, aimed at Go developers and teams who want Redis-style data structures without running a separate Redis server or holding all data in RAM.

What it is

Redka is a key-value store written in Go that speaks the Redis command set and wire protocol (RESP), but stores its data in a relational database rather than in memory. It supports two backends, SQLite and PostgreSQL, and can run either as an in-process library inside a Go application or as a standalone Redis-compatible server. The project lives in the Go ecosystem and is licensed under BSD-3-Clause. It implements five core Redis data types — strings, lists, sets, hashes and sorted sets — plus commands for key management, server and connection management, and transactions.

The concrete problem it solves is the operational cost of Redis itself. A conventional Redis deployment requires a separate server process, a separate data store to provision and monitor, and enough RAM to hold the entire working set. Redka replaces that separate in-memory server with the SQL database the application may already run. Data does not have to fit in RAM, transactions are ACID, and the stored data is exposed through SQL views for easier analysis and reporting. For a Go project that already uses SQLite or PostgreSQL, this removes a component from the stack while keeping the Redis client API that existing code and libraries expect.

Key capabilities

• Implements the Redis wire protocol (RESP) and the Redis command set, so existing Redis clients can connect without modification.
• Supports five Redis data types: strings, lists, sets, hashes and sorted sets (zsets).
• Provides commands for key management, server and connection management, and transactions.
• Runs against either SQLite or PostgreSQL as the storage backend.
• Stores data in a relational database with a simple schema and provides SQL views for introspection and reporting.
• Runs in two flavors: as a standalone Redis-compatible server, or as an in-process Go module.
• Handles tens of thousands of operations per second, per the project benchmarks.

Who uses it and how

• Go applications that already use SQLite and want an embedded cache or key-value store without operating a second server; Redka's in-process mode removes that dependency entirely.
• Development and integration test setups where a real Redis server is a hassle; an in-memory backend gives fast, fully isolated state for each test run as an alternative to test containers, with example code at example/server/main.go.
• PostgreSQL-first teams that want Redis-style data structures — lists, maps and sets, not just get/set with expiration — inside the database they already use, with the same tools and transactional guarantees applied to both relational data and specialized structures.
• Small-scale production deployments that accept moderate throughput in exchange for running on an existing SQL database.

Getting started

Redka ships as a standalone Redis-compatible server with installation and usage documented in docs/install-standalone.md and docs/usage-standalone.md, and as a Go module for in-process use documented in docs/install-module.md and docs/usage-module.md.

How it compares

Against Redis, which the project credits as its inspiration, Redka trades raw speed for persistence and portability: a general-purpose relational backend cannot beat a specialized in-memory data store, but it lets the dataset exceed available RAM and gives ACID transactions and SQL views instead. Against SQLite and PostgreSQL, which serve as its own backends, it adds the Redis data structures and API on top of the relational storage the application already has. It occupies the space between those tools rather than replacing any of them outright.

When to use it — and when not to

A self-hoster still operates the underlying storage — SQLite file or PostgreSQL instance — and accepts lower throughput than Redis, though the project reports tens of thousands of operations per second. The README states Redka is stable and suited to testing and non-critical production scenarios, and that it is in maintenance mode with no new features planned, so teams needing active feature development or maximum performance should not pick it. It is also a largely one-man project, which is worth weighing for long-term support.