KiviDB가 Redis 호환 메모리 데이터베이스를 공개했다

KiviDB는 Rust로 작성한 멀티스레드 메모리 데이터베이스로, Redis·Valkey 호환 명령과 전문·벡터 검색을 제공한다. 제작자는 32코어 환경에서 파이프라인 GET 처리량이 초당 2,100만 건이라고 밝혔다. 이 수치는 특정 AWS 환경에서 진행한 한 차례 측정 결과이며, 실제 성능은 하드웨어와 작업 부하에 따라 달라질 수 있다.

KiviDB는 Redis 프로토콜 RESP2와 RESP3를 사용하므로 기존 Redis 클라이언트, redis-cli, 라이브러리를 변경 없이 사용할 수 있다고 설명한다. 모든 코어에서 샤딩된 인메모리 키-값 구조로 명령을 처리하며, 스냅샷과 선택형 추가 전용 파일(AOF)에 데이터를 저장한다. 기본 포트는 Redis의 6379가 아닌 6380이다. 따라서 두 서버를 나란히 실행할 수 있으며, 클라이언트의 포트를 6380으로 지정하거나 --port 6379를 전달하면 된다.

docker run -d -p 6380:6380 kividb/kividb
redis-cli -p 6380 PING # PONG

지원 명령은 COMMANDS.md에 정리돼 있다. Redis Stack 스타일의 FT.* 명령으로 전문, 태그, 숫자, 벡터 검색을 지원하며 벡터 검색은 FLAT 또는 HNSW 방식을 쓴다. Lua 스크립팅과 TLS는 선택 기능이다. Lua 명령 EVAL, SCRIPT, FUNCTION, FCALL 등은 --features lua로 빌드했을 때 제공된다. 자세한 내용은 Lua 스크립팅 명령을 참조하면 된다. TLS는 --features tls로 켤 수 있다.

기본 수신 주소는 0.0.0.0:6380이며 보호 모드가 켜져 있다. 라이선스는 GNU Affero General Public License v3(AGPL-3.0-only)다. KiviDB 제작자는 네트워크로 KiviDB에 접속하는 애플리케이션은 별도 프로그램이므로 AGPL 적용 대상이 아니라고 설명한다. KiviDB 자체를 수정해 네트워크로 제공하면 수정한 KiviDB의 소스 코드를 이용자에게 제공해야 한다. AGPL을 사용할 수 없거나 수정 내용을 공개하지 않고 KiviDB를 변경·내장하려는 조직에는 상용 라이선스도 제공한다. 저장소는 github.com/kividbio/kividb, 웹사이트는 kividb.io다.

비교와 성능 측정

저장소의 비교표는 2026년 10월 기준이다. KiviDB는 Rust, Redis 8과 Valkey 8은 C, Dragonfly와 KeyDB는 C++로 작성됐다. KiviDB와 Dragonfly는 모든 코어에서 각각 샤딩 및 공유 자원 없는 방식으로 명령을 처리하고, Redis와 Valkey는 I/O 스레드 하나에서 명령을 처리하며 KeyDB는 여러 스레드를 사용한다. 전문·벡터 검색은 KiviDB와 Redis 8에 내장돼 있고, Valkey는 별도 모듈, Dragonfly는 내장 기능으로 제공하며 KeyDB에는 없다. Lua 스크립팅은 KiviDB에서 lua 빌드가 필요하고 나머지 네 제품에서는 지원된다. 표에 제시된 라이선스는 KiviDB AGPL-3.0, Redis 8 RSALv2·SSPLv1 또는 AGPL-3.0, Valkey 8 BSD-3-Clause, Dragonfly BSL 1.1, KeyDB BSD-3-Clause다. 내용이 오래됐거나 잘못된 경우 이슈를 열 수 있다.

제작자가 공개한 모든 성능 수치는 2026년 10월 AWS Graviton3 베어메탈 한 세션에서 얻었다. 서버는 c7gn.metal(64 vCPU)에서 32코어로 제한했고, 부하 생성기는 같은 배치 그룹의 별도 c7gn.metal에서 실행했다. 각 엔진은 서버에서 한 번에 하나씩 실행했다.

키-값 측정에는 kivi-benchmark의 run-matrix.sh를 거친 memtier_benchmark를 사용했다. 키 1,000만 개와 100바이트 값으로 시나리오마다 30초 동안 측정했으며, 두 차례 실행의 평균을 냈다. 파이프라인 측정은 연결 300개, 파이프라인이 없는 측정은 연결 1,200개를 사용했다. 아래 처리량은 초당 연산 수다.

제작자는 같은 32코어 조건의 파이프라인 GET 측정에서 KiviDB가 초당 2,100만 건 이상을 처리해 Redis 8보다 약 9배, Dragonfly보다 2.3배 빠르고, p99 지연시간은 Dragonfly의 절반보다 낮았다고 밝혔다. 다만 이는 한 번의 통제된 측정 결과이지 성능 보장이 아니며, 저장소는 사용자가 자체 하드웨어와 작업 부하에서 측정할 것을 권한다.

벡터 검색 측정은 redis/vector-db-benchmark의 glove-25-angular 데이터(벡터 118만 개, 차원 25)를 사용했다. HNSW 설정은 M=16, EF_CONSTRUCTION=256이며, 클라이언트 100개가 64개씩 묶어 데이터를 올린 뒤 ef 64, 128, 256, 512에서 질의했다.

측정 방법과 스크립트는 kivi-benchmark, 가장 최근 자동 측정 결과는 benchmarks/LATEST.md에 있다.

KiviDB는 Redis Stack 호환 검색·벡터 명령을 구현해 기존 클라이언트와 튜토리얼을 대체로 그대로 쓸 수 있다고 설명한다. 해시 필드에서 BM25 전문 검색, 태그·숫자 필터, FLAT 또는 HNSW를 이용한 근사 최근접 이웃(ANN) 검색을 지원한다. 인덱스를 만들 때 키 접두사와 VECTOR 필드를 하나 이상 지정하고, 필요하면 TEXT, TAG, NUMERIC 필드도 추가한다.

redis-cli -p 6380 FT.CREATE idx ON HASH PREFIX 1 doc: SCHEMA \\
 vec VECTOR HNSW 10 TYPE FLOAT32 DIM 128 DISTANCE_METRIC COSINE M 16 EF_CONSTRUCTION 128

벡터는 해시 필드에 FLOAT32 리틀엔디언 원시 바이트로 저장한다. 필요한 크기는 DIM × 4바이트이며 Redis Stack, redis-py, NumPy 블롭과 같은 규약이다. 클라이언트의 바이너리 안전 HSET을 사용한다. 통합 테스트의 예시는 tests/e2e/에 있다. KNN 질의는 Dialect 2를 사용하고, 질의 벡터는 이름이 지정된 바이너리 매개변수로 전달한다.

redis-cli -p 6380 FT.SEARCH idx '*=>[KNN 10 @vec $q]' PARAMS 2 q <blob> DIALECT 2

전체 명령, 필터, 하이브리드 검색, 예외 사례는 COMMANDS.md에서 FT.CREATE, FT.SEARCH, FT.HYBRID 등을 검색하면 확인할 수 있다.

저장, 빌드와 실행

기본 스냅샷 dump.kdb에는 키와 인덱스 스키마가 저장된다. 인덱스가 채워진 상태에서 SAVE 또는 BGSAVE를 실행하면 각 벡터 필드의 HNSW 그래프도 저장되므로 재시작 뒤 검색 품질이 종료 전 그래프와 같다고 설명한다. 시작할 때 검색 인덱스를 다시 만드는 동안 대부분의 명령은 재구축이 끝날 때까지 LOADING을 반환한다. PING, INFO 등 일부 명령은 계속 동작한다. 대량 적재 뒤 SAVE를 실행하거나 BGSAVE를 예약하면, 다음 시작 때 해시에서 그래프를 다시 만드는 대신 디스크의 그래프를 불러올 수 있다.

Cargo 기능으로 선택하는 빌드 변형은 네 가지다. default는 Lua와 TLS가 없는 핵심 서버, lua는 EVAL, EVALSHA, SCRIPT, FUNCTION, FCALL 등의 Lua 스크립팅, tls는 TLS 수신 포트와 클러스터 노드·복제본 사이의 TLS, full은 Lua와 TLS를 모두 포함한다. Lua 없는 빌드에서 스크립팅 명령은 오류를 반환한다. TLS 없는 빌드에 --tls-port를 지정하면 평문으로 서비스를 제공하는 대신 시작을 거부한다.

소스 빌드에는 안정판 Rust 도구 체인이 필요하다. rust-toolchain.toml은 rustfmt와 clippy를 포함한 stable을 선택한다. 크레이트는 2024 에디션을 사용하며, 검사 대상의 가장 오래된 도구 체인은 Rust 1.89다. Dockerfile도 이 버전으로 빌드한다.

git clone https://github.com/kividbio/kividb.git
cd kividb

cargo build --release # default variant
cargo build --release --features lua # with Lua scripting
cargo build --release --features tls # with TLS
cargo build --release --features lua,tls # full

./target/release/kividb

Linux에서는 커널이 허용하면 io_uring을 사용하고, 그렇지 않으면 Tokio로 전환한다. 기본 설정은 --io-model auto다. Docker 이미지를 직접 만들 때 기본 변형은 docker build -t kividb .로 빌드한다. 다른 변형은 docker build --build-arg KIVIDB_FEATURES=lua,tls -t kividb:full .을 사용한다.

./target/release/kividb # listens on 0.0.0.0:6380
redis-cli -p 6380 PING

Redis 클라이언트는 포트 6380을 지정해 사용할 수 있다. 보호 모드는 기본적으로 켜져 있다. --bind나 설정 파일의 bind로 주소를 지정하지 않았고 default 사용자에 비밀번호도 없으면, 같은 머신의 루프백 클라이언트만 접속할 수 있다. 다른 클라이언트는 선택지를 설명하는 -DENIED 오류를 받고 연결이 끊긴다. 외부 머신의 접속을 허용하려면 --requirepass <password> 또는 ACL SETUSER default ><password>로 비밀번호를 설정하거나, --bind <address>로 수신 주소를 지정하거나, --protected-mode no, 설정 파일의 protected-mode no, 로컬 클라이언트에서 실행하는 CONFIG SET protected-mode no로 보호 모드를 끌 수 있다. 보호 모드를 끄거나 공개 주소에 바인딩할 경우 인터넷에서 비밀번호 없이 서버에 접근할 수 없도록 해야 한다.

Docker Hub와 GitHub Container Registry에는 같은 태그의 이미지가 공개돼 있다. latest와 v1.1.0 같은 버전 태그는 기본 변형이고, 다른 변형은 v1.1.0-lua, v1.1.0-tls, v1.1.0-full이다. 이미지는 amd64와 arm64용으로 빌드된다.

docker pull kividb/kividb:latest
# or
docker pull ghcr.io/kividbio/kividb:latest

docker run -p 6380:6380 kividb/kividb

컨테이너는 루프백이 아니라 네트워크를 통해 접속하므로 이미지의 기본 명령은 --protected-mode no다. 사용자가 전달한 인수는 이 기본값을 대체해 보호 모드를 다시 켠다. 자체 플래그를 전달할 때는 비밀번호를 설정하거나(권장) --protected-mode no를 직접 추가해야 한다.

docker run -p 6380:6380 ghcr.io/kividbio/kividb \\
 --requirepass "change-me" \\
 --databases 8 \\
 --loglevel debug

AOF를 사용하려면 데이터가 재시작 뒤에도 남도록 볼륨을 마운트한다. 서버는 /home/kividb에서 kividb 사용자로 실행된다.

docker run -p 6380:6380 \\
 -v $(pwd)/data:/home/kividb \\
 ghcr.io/kividbio/kividb --aof --requirepass "change-me"

--aof를 켜면 모든 쓰기가 appendonly.aof에 추가되고 시작할 때 재생된다. 따라서 충돌이 나도 마지막 스냅샷 이후의 모든 데이터가 사라지는 대신, 최대 약 1초의 쓰기(fsnyc 간격)만 손실된다. AOF가 있으면 스냅샷은 불러오지 않으며 그 이유는 docs/PERSISTENCE.md에 설명돼 있다.

Docker의 기본 seccomp 프로필은 최근 버전에서 컨테이너의 io_uring을 차단하므로 KiviDB는 Tokio로 전환한다. Linux 호스트에서 이를 허용하려면 --security-opt seccomp=unconfined를 사용한다. 운영 환경에서 쓰기 전에 이 설정이 허용하는 범위를 이해해야 한다.

Linux(x86_64, aarch64)와 macOS(Apple silicon, Intel)용 릴리스 바이너리는 GitHub Releases에 공개된다. 아래 latest/download 링크는 항상 최신 릴리스를 가리킨다. 특정 버전을 고정하려면 latest/download를 download/v1.1.0으로 바꾼다.

# Linux x86_64
curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb-linux-x86_64.tar.gz
tar xzf kividb-linux-x86_64.tar.gz
./kividb

# Linux aarch64 (an ARMv8.1 CPU or newer: Graviton2 and later, Ampere; not a Raspberry Pi 4)
curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb-linux-aarch64.tar.gz

# macOS, Apple silicon / Intel
curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb-darwin-aarch64.tar.gz
curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb-darwin-x86_64.tar.gz

기본 변형이 아닌 빌드 파일에는 변형 이름이 붙는다. 예를 들어 kividb-lua-linux-x86_64.tar.gz, kividb-tls-…, kividb-full-…이다. 기본 변형은 Linux용 kividb_amd64.deb·kividb_arm64.deb, kividb.x86_64.rpm·kividb.aarch64.rpm 패키지로도 제공된다. 패키지는 nfpm으로 packaging/nfpm.yaml을 사용해 빌드한다. 릴리스의 SHA256SUMS.txt에는 모든 파일의 체크섬이 들어 있다.

curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb_amd64.deb && sudo dpkg -i kividb_amd64.deb
curl -LO https://github.com/kividbio/kividb/releases/latest/download/kividb.x86_64.rpm && sudo rpm -i kividb.x86_64.rpm

설정과 TLS

KiviDB는 명령줄 플래그나 Redis 스타일 설정 파일로 설정한다. 파일에는 port 6380, appendonly yes처럼 한 줄에 지시문 하나를 쓴다. /etc/kividb/kividb.conf가 있으면 이를 읽고, 다른 파일은 --configfile <path>로 지정한다. 명령줄 플래그와 파일의 설정이 겹치면 플래그가 우선한다. 전체 옵션은 kividb --help에서 확인할 수 있다.

TLS 클라이언트는 별도 포트 --tls-port로 접속하고, 평문 연결은 --port에 남는다.

cargo build --release --features tls
./target/release/kividb --port 6380 --tls-port 6381 --tls-cert-file cert.pem --tls-key-file key.pem
redis-cli --tls -p 6381 --cacert ca.pem # ca.pem: the CA that signed cert.pem

--tls-ca-cert-file ca.pem을 지정하면 해당 CA가 서명한 인증서를 클라이언트가 제시해야 하며, 그렇지 않으면 핸드셰이크 단계에서 거부한다. --tls-auth-clients optional은 인증서가 없는 클라이언트를 허용하지만 유효하지 않은 인증서는 거부한다. --tls-auth-clients no는 인증서를 요구하지 않는다. redis-cli에서는 다음과 같이 연결한다.

redis-cli --tls -p 6381 --cacert ca.pem --cert client.pem --key client.key

클라이언트는 TLS 포트에서 TLS를 사용해야 한다. 예를 들어 --tls 없이 redis-cli -p 6381로 평문 연결을 시도하면 핸드셰이크가 실패하고 서버에 [TLS] handshake failed가 기록된다. memtier_benchmark에서는 --tls를 추가하고 자체 서명 인증서라면 --tls-skip-verify도 추가한다.

로그는 표준 오류 또는 --logfile로 출력한다. docs/LOGGING.md는 로그를 설명하고, docs/ERRORS.md는 경고·오류·오류 응답과 각각의 대응 방법을 설명한다.

릴리스 빌드의 KiviDB는 시작할 때 https://github.com/kividbio/kividb/releases/latest로 HTTPS 요청을 한 번 보낸다. 이 주소는 최신 릴리스를 찾으려고 열 수 있는 페이지와 같다. GitHub는 최신 릴리스의 태그로 리디렉션하며, 실행 중인 빌드보다 새 버전이면 시작 배너 앞에 링크와 간단한 알림을 출력한다. 요청 외에는 아무것도 보내지 않으며 User-Agent는 kividb/<version>이다. 호스트 이름, 설정, 키, 데이터, 식별자는 전송하지 않는다. GitHub는 다른 웹 서버와 마찬가지로 요청의 출발지 IP 주소를 본다.

응답을 기다리는 시간은 최대 1.5초다. 실패는 디버그 수준으로만 기록하고 클라이언트에는 영향을 주지 않는다. 응답에서 버전 형식에 맞는 태그만 허용하며 그 밖의 내용은 출력하지 않는다. 확인 기능은 명령줄의 --update-check no, 설정 파일의 update-check no, 환경 변수 KIVIDB_NO_UPDATE_CHECK=1 중 하나로 끌 수 있다. 디버그 빌드이거나 CI 환경 변수가 설정된 경우에도 요청하지 않는다. 폐쇄망 내부 미러처럼 다른 HTTPS 주소를 쓰려면 --update-check-url로 지정한다. 자세한 내용은 docs/UPDATE_CHECK.md에 있다.

기여, 보안과 라이선스

기여를 환영한다. 빌드·테스트·변경 사항 제출 방법은 CONTRIBUTING.md에 있다. 기여는 첫 풀 리퀘스트 때 서명하는 Contributor License Agreement에 따라 접수한다. 행동 강령을 따라야 하며, 릴리스별 변경 내용은 Changelog에 정리돼 있다.

보안 취약점을 공개 이슈로 신고하지 말아야 한다. 비공개 신고 방법은 SECURITY.md를 참조한다.

저작권은 Copyright (c) 2026 KIVIDB PRIVATE LIMITED다. KiviDB는 OSI 승인 라이선스인 GNU Affero General Public License, version 3(AGPL-3.0-only)로 배포되는 오픈소스 소프트웨어다. 조건에 따라 사용·수정·재배포할 수 있으며 NOTICE도 참고할 수 있다.

KiviDB 제작자는 네트워크를 통해 어떤 Redis 클라이언트로든 KiviDB에 연결하는 애플리케이션은 별도 프로그램이며, 애플리케이션 코드에 공개 의무가 없다고 설명한다. 수정하지 않은 KiviDB를 공개·비공개, 상업·비상업 제품에서 데이터베이스로 사용할 수 있다. AGPL이 GPL에 더해 요구하는 사항은 KiviDB 자체를 수정하고 호스팅 서비스처럼 네트워크로 다른 사람이 쓰게 할 경우, 해당 이용자에게 수정한 KiviDB의 소스 코드를 제공하는 것이다. KIVIDB PRIVATE LIMITED는 AGPL 소프트웨어를 쓸 수 없거나 수정 내용을 공개하지 않고 KiviDB를 변경·내장하려는 조직을 위해 상용 라이선스도 제공한다. 문의 주소는 support@kividb.io다.

제작자는 AGPLv3로 배포한 모든 KiviDB 버전을 계속 AGPLv3로 제공하겠다고 밝혔다. Contributor License Agreement는 오픈소스 버전을 없애기 위한 것이 아니라 상용 라이선스를 함께 제공할 수 있게 한다고 설명한다. FAQ에서는 수정하지 않은 KiviDB를 서비스로 운영할 때 공개할 소스가 없고, KiviDB를 수정해 네트워크로 제공할 때에는 서비스 이용자에게 수정본 소스를 제공해야 한다고 답한다. Redis 클라이언트, 설정 파일, KiviDB에 보내는 스크립트와 함수는 KiviDB 자체의 수정에 해당하지 않는다고 덧붙인다.

Redis®는 Redis Ltd.의 등록 상표이며 관련 권리는 Redis Ltd.에 있다. KiviDB의 상표 사용은 지칭을 위한 것이며 Redis의 후원·승인·제휴를 의미하지 않는다. KiviDB는 Redis Ltd.와 제휴 관계가 없다. 그 밖에 언급된 이름은 각 소유자의 상표다.