filedb: Store Key-Value Data in Append-Only Disk Logs

Overview

FileDB is a disk-based key-value store implemented in Zig and inspired by the Bitcask design. It appends writes to data files and tracks each record's location in an in-memory index, aiming to make lookups direct while avoiding storing full values in memory.

It is intended for developers who want an embeddable storage library or a Redis-compatible service with a simple key-value interface. The repository describes compaction and syncing, but does not provide evidence of production readiness or guarantees around durability and concurrency.

Key Features

• Append-only writes to an active data file, with older files retained for reads.
• In-memory metadata maps keys to their file and record positions.
• Compaction combines data files and updates the metadata index.
• Periodic syncing, with an option to sync on every request.
• Library methods for inserting, retrieving, deleting, and listing keys.
• Hint files can store and reload the key directory.
• Includes a Redis-compatible client interface.

Use Cases

• Zig developers evaluating a compact local key-value storage layer for an application.
• Projects that need append-oriented writes and can accept an in-memory index of record metadata.
• Developers prototyping a Redis-compatible service for basic key-value access.
• Learning or experimentation with Bitcask-style storage, log files, and compaction.

Project Facts

• Language: Zig
• Stars: 198
• Forks: 7
• Archived: No

Getting Started

Start with the repository README for library and Redis-compatible client details. No installation command is provided in the supplied README.

Alternatives

• tidesdb: TidesDB is an embeddable C LSM-based engine with transactions, column families, and range scans; FileDB is a Zig append-only store with an in-memory index.

Considerations

The repository was created in June 2025 and its supplied metadata shows its last push in June 2025, so treat it as an early-stage project and assess its suitability before relying on it for important data. The README does not specify a license, compatibility requirements, or operational guarantees. Its stated O(1) lookup benefit depends on keeping the metadata index in memory, and syncing behavior affects the durability/performance tradeoff.