Frequently Asked Questions

Korvet is a Kafka-compatible streaming service backed by Redis Streams, with optional tiered storage to an Apache Iceberg table on an object store for long-term archival.

Korvet is in active development. The core features are functional:

Any Kafka client that supports the Kafka protocol should work. Tested clients include:

Supported:

Not supported:

Yes, with a region-pinned topic design: each topic is produced from exactly one region (for example orders-region1, orders-region2), and consumers subscribe to all regional variants through their local brokers. The Active-Active database replicates every region’s topics everywhere for consumption. See Active-Active Databases (CRDB) for the topology and the rules to follow.

Yes, but with some considerations:

Performance depends on your Redis instance and configuration. With async operations and pipelining:

See the load-testing sample for benchmarking tools.

Korvet is stateless and can be scaled horizontally:

See Partition Leadership for how traffic is distributed.

Minimum:

Recommended for production:

As long as your Redis instance has capacity. Configure retention policies (the Kafka-compatible topic config keys retention.ms and retention.bytes, or the retention-time/retention-bytes keys on a korvet.topics pattern) to trim old messages. Trimming is enforced asynchronously by a leader-locked background storage worker (via Redis XTRIM), not at write time.

You have several options:

Yes. The remote tier is a standard Apache Iceberg table (Parquet data files plus Iceberg metadata and manifests), so external query engines such as Spark, Trino, Athena, and DuckDB can read it directly. Korvet clients also read archived data transparently through the normal Kafka fetch API — the broker reads from the remote tier on their behalf.

See Remote Storage for configuration details.

It depends on your data structure and message size:

Use JSON flattening (default for JSON objects):

Use RAW + storage compression:

Storage compression is applied per record value, so plain codecs only pay off for values of roughly 1-4 KB and above. For large values, start with ZSTD for storage efficiency, or SNAPPY when CPU cost matters more than the last few percentage points of compression. For small values — typical few-hundred-byte log events — a single record barely compresses on its own even when the stream as a whole is highly repetitive; use ZSTD there too, which enables per-topic dictionary compression by default to recover the cross-record redundancy.

Example: For log messages with deep nesting, RAW+ZSTD can reduce Redis memory usage by 18x compared to JSON flattening.

See Value Mapper Selection for detailed guidance and performance comparisons.

Based on production testing with 100KB messages:

Actual compression ratios depend on your data and — because compression is per record value — on value size. Repetitive data (logs, structured text) compresses better than random data (images, encrypted data), but a plain codec only sees redundancy within a single value: a few-hundred-byte log event compresses only ~1.3x on its own, so the ratios above apply to large values. For small records, ZSTD topics train a per-topic dictionary by default, which restores useful ratios by capturing the redundancy that repeats across records.

Korvet exposes metrics via Prometheus and health checks via Spring Boot Actuator. See Monitoring.

Yes! See Deployment guide for Kubernetes manifests.

See the GitHub repository for contribution guidelines.

File an issue at https://github.com/redis-field-engineering/korvet-dist/issues

Check the GitHub issues and project boards for planned features.