nalgeon/redka

Redis re-implemented with SQL

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 55 minutes ago
Added to GitGenius on September 15th, 2026
Created on April 6th, 2024
Open Issues & Pull Requests: 0 (+0)
GitHub issues: Enabled
Number of forks: 135
Total Stargazers: 4,567 (+0)
Total Subscribers: 34 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 3.1 hours
Mean response time: 37.4 hours
90th percentile: 4.7 days
Tracked items: 16

Most active contributors

Sign in to see contributor activity.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 0
New in 7 days: 0
Closed in 7 days: 0
Avg open age: N/A days
Stale 30+ days: 0
Stale 90+ days: 0

Recent activity

Opened in 7 days: 0
Closed in 7 days: 0
Comments in 7 days: 0
Events in 7 days: 0

Top labels

No label distribution available yet.

Most active issues this week

No issue events were indexed in the last 7 days.

Detailed Description

Redka is a key-value database that reimplements Redis using SQL as its backend while maintaining compatibility with the Redis API.

The project solves the problem of needing Redis-like functionality without the constraint of in-memory storage or the operational overhead of running a separate server. It achieves this by implementing Redis commands and the RESP wire protocol on top of SQLite or PostgreSQL, allowing data to exceed available RAM and providing ACID transaction guarantees. The tool supports five core Redis data types—strings, lists, sets, hashes, and sorted sets—along with key management, server commands, and transactions. It can run either as an in-process Go library or as a standalone server.

Redka suits three primary scenarios. For Go applications that already use SQLite or need an embedded key-value store, it provides Redis-like features without requiring a separate server. For development and testing environments, it offers a lightweight alternative to test containers with full test isolation. For teams committed to PostgreSQL, it enables Redis-like data structures within an existing database, unifying relational and specialized data management under the same transactional guarantees. The README notes that raw performance is not a design goal; while the tool can handle tens of thousands of operations per second, it cannot match a specialized store like Redis. The project is stable for testing and non-critical production use but is in maintenance mode with no new features planned.

Development activity shows a mature, stable codebase with contributions welcome for bugfixes and issues opened for feature discussions. Testing is required for all changes, and the project maintains comprehensive documentation including command references, installation guides, usage examples, and performance benchmarks.