KiviDB: Redis-совместимая БД на Rust в 9× быстрее

28 октября 2026 г.

#in-memory#key-value#performance#redis#rust#vector-search
Логотип KiviDB

KiviDB — быстрая многопоточная альтернатива Redis® и Valkey, написанная на Rust. Она поддерживает протокол Redis (RESP2 и RESP3), поэтому существующие клиенты Redis, redis-cli и библиотеки работают без изменений; кроме того, в неё встроены полнотекстовый и векторный поиск. Сервер задействует каждое ядро благодаря шардированному хранилищу ключ–значение в памяти, а для персистентности использует снапшоты и опциональный журнал дозаписи (append-only file).

На тех же 32 ядрах KiviDB обрабатывает 21 миллион конвейеризованных (pipelined) GET-запросов в секунду — примерно в 9 раз больше Redis 8 и в 2,3 раза больше Dragonfly, при этом p99-задержка вдвое ниже, чем у Dragonfly (подробности — в разделе Производительность).

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

KiviDB слушает порт 6380, а не стандартный Redis-порт 6379 — оба сервера могут работать одновременно. Направьте клиент на этот порт или передайте --port 6379.

  • Протокол: совместимый с Redis набор команд (поддерживаемые команды перечислены в COMMANDS.md)

  • Поиск и векторы: команды FT.* в стиле Redis Stack — полнотекстовый поиск, теги, числовые поля и векторный поиск ANN (FLAT / HNSW)

  • Сценарии Lua: опциональная фича Cargo; команды EVAL, SCRIPT, FUNCTION, FCALL и связанные с ними доступны в сборках с --features lua (см. Scripting commands (Lua))

  • TLS: опциональная фича Cargo (--features tls)

  • Адрес по умолчанию: 0.0.0.0:6380 с включённым защищённым режимом

  • Лицензия: GNU Affero General Public License v3 (AGPL-3.0-only), открытый исходный код; использование KiviDB не распространяет действие AGPL на ваше приложение (подробности — в разделе Лицензия)

Репозиторий: github.com/kividbio/kividb · Сайт: kividb.io

Переходите с Redis? Руководство по миграции · Совместимость и отличия · Примеры клиентов · Бенчмарки · Релизы · Kubernetes-оператор

Сравнение с конкурентами

KiviDB Redis 8 Valkey 8 Dragonfly KeyDB

Лицензия

AGPL-3.0

RSALv2, SSPLv1 или AGPL-3.0

BSD-3-Clause

BSL 1.1

BSD-3-Clause

Язык

Rust

C

C

C++

C++

Выполнение команд

каждое ядро (шардирование)

один поток (I/O-потоки)

один поток (I/O-потоки)

каждое ядро (shared-nothing)

несколько потоков

Полнотекстовый и векторный поиск (FT.*)

встроен

встроен (Query Engine)

отдельный модуль

встроен

нет

Скриптинг Lua

сборка lua

да

да

да

да

Данные актуальны на октябрь 2026 года. Если что-то устарело или неверно, откройте issue.

Производительность

Бенчмарки KiviDB: пропускная способность, задержка, векторный поиск и векторная загрузка

Пропускная способность, задержка, векторный поиск и векторная загрузка. Нажмите для просмотра видео в полном разрешении.

Все приведённые ниже результаты получены в ходе одной сессии в октябре 2026 года на AWS Graviton3 bare metal: сервер на c7gn.metal (64 vCPU), ограниченный 32 ядрами, и генератор нагрузки на втором c7gn.metal в той же группе размещения. Каждый движок запускался на сервере по очереди, в одиночестве.

Ключ–значение

Тест с помощью memtier_benchmark через run-matrix.sh из kivi-benchmark: 10 миллионов ключей, значения по 100 байт, 30 секунд на сценарий, среднее из двух прогонов; 300 соединений с конвейеризацией и 1 200 без неё.

Пропускная способность с конвейеризацией: KiviDB, Dragonfly, Redis, Redis Cluster
ops/s KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 Redis Cluster (32 шарда)

GET, pipeline 16

21,2M

9,1M

2,4M

4,7M

SET, pipeline 16

19,2M

8,5M

2,0M

4,7M

GET, без конвейеризации

3,07M

3,35M

1,32M

1,46M

SET, без конвейеризации

3,12M

3,38M

1,54M

1,46M

p99-задержка, GET / SET, pipeline 16

0,36 / 0,42 мс

0,88 / 1,07 мс

2,2 / 2,7 мс

Память на ключ

177 Б

134 Б

178 Б

183 Б
p99-задержка с конвейеризацией

Векторный поиск

redis/vector-db-benchmark на наборе данных glove-25-angular (1,18M векторов, 25 измерений): HNSW с M=16 и EF_CONSTRUCTION=256, 100 клиентов, загружающих данные пакетами по 64 вектора, затем запросы при ef 64, 128, 256 и 512.

Векторный поиск: количество запросов в секунду и точность поиска (recall)
KiviDB 1.1.0 Dragonfly 2.0.2 Redis 8.10 (query engine)

Запросов/с при ef 64 (recall@10)

59,3k (0,943)

41,3k (0,912)

31,8k (0,912)

Запросов/с при ef 128

50,7k (0,961)

40,3k (0,937)

28,9k (0,937)

Запросов/с при ef 256

31,5k (0,989)

36,2k (0,979)

21,1k (0,979)

Запросов/с при ef 512

18,7k (0,998)

29,8k (0,995)

13,7k (0,995)

Загрузка и построение индекса

31 с

13 с

38 с

Память после загрузки

1,66 ГБ

1,13 ГБ

1,07 ГБ
Время загрузки векторов

Нагрузка до насыщения

Второй тест — на Azure, по методике latency/throughput/saturation: вместо фиксированной нагрузки каждые 30 секунд добавляются клиенты (от 40 до 1 600 на базу данных) вплоть до насыщения сервера. Каждый клиент посылает 10 конвейеризованных пар SET+GET по 10 миллионам ключей, затем делает паузу 10 мс. Каждый сервер работал на отдельной VM с 8 vCPU arm64 (D8ps_v5); Redis Cluster — на четырёх VM по 2 vCPU (итого 8 vCPU). KiviDB 1.1.2, октябрь 2026 года.

KiviDB против Dragonfly, Redis и Redis Cluster при нарастающей нагрузке: пропускная способность, p50 и p99 задержка, ошибки, CPU и память

Весь прогон — 20 минут с ускорением 60×. Нажмите для просмотра видео в полном разрешении.

Пиковая пропускная способность p50 / p99 при 1 600 клиентах Ошибки

KiviDB 1.1.2

2,08M req/s

4,3 / 13,9 мс

0

Dragonfly 2.0.2

1,56M req/s

10,1 / 33,9 мс

0

Redis 8.10.2 Cluster (4 × 2 vCPU)

0,97M req/s

26,8 / 44,9 мс

0

Redis 8.10.2

0,49M req/s

55,2 / 72,1 мс

0

Задержка измерена на пакет конвейеризованных запросов. Без конвейеризации KiviDB показал примерно на 20% меньше, чем Dragonfly на этих машинах (около 8% на bare-metal). Обвязка теста, исходные данные и видео прогона находятся в kivi-benchmark/ramp-saturation; дашборд прогона — снапшот Grafana.

Результаты зависят от среды. Публикуемые цифры — это один контролируемый замер, а не гарантия; измеряйте на своём железе и своей нагрузке.

Векторный поиск (команды FT.* в стиле Redis Stack)

KiviDB реализует совместимые с Redis Stack команды поиска и работы с векторами, поэтому существующие клиенты и руководства в основном работают без изменений. Их можно применять для полнотекстового поиска (BM25), тегов и числовых полей, а также векторного ANN (FLAT или HNSW) по полям хешей.

Быстрый старт

  1. Создайте индекс по ключам с заданным префиксом, объявив хотя бы одно поле VECTOR (HNSW или FLAT) и опциональные поля 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

  1. Сохраняйте векторы в виде сырых байтов FLOAT32 в little-endian-порядке в поле хеша (DIM × 4 байт) — тот же формат, что в Redis Stack и в блобах redis-py / numpy. Используйте бинарно-безопасный HSET вашего клиента (примеры есть в интеграционных тестах в tests/e2e/).

  2. Выполните запрос с KNN (Диалект 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), чтобы при следующем запуске граф был загружен с диска, а не перестроен из хешей.

Варианты сборки

KiviDB поставляется в четырёх вариантах, которые выбираются через флаги Cargo features во время сборки:

Вариант Cargo features Добавляет

default

нет

основной сервер без Lua и TLS

lua

lua

Lua-скриптинг (EVAL, EVALSHA, SCRIPT, FUNCTION, FCALL, …)

tls

tls

TLS-листенер, а также TLS между узлами кластера и репликами

full

lua,tls

оба варианта

В сборке без Lua команды скриптинга возвращают ошибку. Сборка без TLS откажется запускаться, если указан --tls-port, вместо того чтобы работать в режиме открытого текста.

Сборка из исходников

Требуется стабильная (stable) цепочка инструментов Rust (rust-toolchain.toml задаёт stable с rustfmt и clippy). Крейт использует редакцию 2024; самая старая проверяемая версия Rust — 1.89, именно с ней собирает Dockerfile.

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

cargo build --release                      # вариант по умолчанию
cargo build --release --features lua       # со скриптингом Lua
cargo build --release --features tls       # с TLS
cargo build --release --features lua,tls   # полная сборка

./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 . — другой вариант.

Запуск KiviDB

./target/release/kividb                    # слушает на 0.0.0.0:6380
redis-cli -p 6380 PING

Подойдёт любой Redis-клиент — направьте его на порт 6380.

Защищённый режим (Protected mode)

Защищённый режим включён по умолчанию, как и в Redis. Пока он активен, адрес привязки не задан (--bind или bind в файле конфигурации) и пользователь default не имеет пароля — подключаться могут только клиенты на той же машине (через loopback). Любой другой клиент получает ошибку -DENIED с объяснением вариантов и сразу отключается.

Чтобы принимать клиентов с других машин, выполните одно из следующего:

  • задайте пароль: --requirepass <password> или ACL SETUSER default ><password>;

  • задайте адрес привязки: --bind <address>;

  • отключите защищённый режим: --protected-mode no, protected-mode no в файле конфигурации или CONFIG SET protected-mode no с локального клиента.

Если вы отключаете режим или привязываетесь к публичному адресу, убедитесь, что сервер недоступен из интернета без пароля.

Пакеты для Linux

На странице релизов опубликованы пакеты .deb и .rpm для архитектур amd64 и arm64. Они устанавливают бинарный файл, юнит systemd, системного пользователя kividb и стандартный /etc/kividb/kividb.conf, настроенный на прослушивание только loopback. Установка автоматически включает и запускает юнит; обновление перезапускает его:

sudo apt install ./kividb_amd64.deb     # или: sudo rpm -i kividb.x86_64.rpm
redis-cli -p 6380 PING

Данные (снапшот, AOF, nodes.conf) хранятся в /var/lib/kividb, логи идут в журнал: journalctl -u kividb. Чтобы принимать клиентов с других машин, задайте пароль и измените bind в /etc/kividb/kividb.conf.

Docker

Образы публикуются на Docker Hub и в GitHub Container Registry с одинаковыми тегами в обоих реестрах:

docker pull kividb/kividb:latest
# или
docker pull ghcr.io/kividbio/kividb:latest

latest и теги версий вида v1.1.0 соответствуют варианту по умолчанию; v1.1.0-lua, v1.1.0-tls и v1.1.0-full — остальным вариантам. Образы собраны для amd64 и arm64.

docker run -p 6380:6380 kividb/kividb

Контейнер доступен через сеть, а не через loopback, поэтому в команде запуска образа по умолчанию задан --protected-mode no. Аргументы, которые вы передаёте, заменяют это значение по умолчанию, то есть защищённый режим включается снова. Если вы передаёте собственные флаги, задайте пароль (рекомендуется) или явно добавьте --protected-mode no:

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

С персистентностью AOF (подключите том, чтобы данные пережили перезапуск; сервер работает как UID 1000 в /home/kividb):

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

При --aof каждая запись добавляется в appendonly.aof и воспроизводится при старте: в случае сбоя теряется не более примерно последней секунды записей (интервал fsync), а не всё накопленное с момента последнего снапшота. Если AOF присутствует, он является источником истины и снапшот не загружается — подробности в docs/PERSISTENCE.md.

Образ дистроless: в нём нет ни оболочки, ни redis-cli. Подключайтесь из другого контейнера, например: docker run --rm -it --network container:<name> redis redis-cli -p 6380.

io_uring в контейнерах: стандартный профиль seccomp Docker блокирует io_uring в последних версиях, и KiviDB переключается на Tokio. Чтобы разрешить io_uring на 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 (CPU ARMv8.1 и новее: Graviton2 и выше, Ampere; 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

Начиная с версии 1.2.0 каждый файл релиза и каждый образ содержат подписанное подтверждение происхождения сборки — GitHub artifact attestation, удостоверяющее, что артефакт был собран рабочим процессом этого репозитория из помеченного коммита. Контрольная сумма подтверждает целостность загрузки, аттестация — подлинность источника. Через GitHub CLI:

gh attestation verify kividb-linux-x86_64.tar.gz --repo kividbio/kividb
gh attestation verify oci://ghcr.io/kividbio/kividb:v1.2.0 --repo kividbio/kividb

Конфигурация

KiviDB настраивается с помощью флагов командной строки или файла конфигурации в стиле Redis (по одной директиве на строку, например port 6380 или appendonly yes). Файл читается из /etc/kividb/kividb.conf, если он существует; --configfile <path> позволяет указать другой. Флаг командной строки имеет приоритет над соответствующей настройкой в файле. Полный список параметров — в выводе kividb --help.

Флаг По умолчанию Описание

--port

6380

Порт прослушивания

--bind

0.0.0.0

Адрес прослушивания. Явное задание отключает защищённый режим

--protected-mode <yes|no>

yes

См. Защищённый режим

--threads

0 (авто)

Рабочие потоки; авто — количество ядер минус 2 (все ядра, если их менее 4)

--databases

16

Количество баз данных

--dir <path>

рабочий каталог

Где хранятся dump.kdb, appendonly.aof и nodes.conf

--aof

выкл.

Персистентность через журнал дозаписи (append-only file)

--maxmemory <bytes>

0 (без ограничений)

Ограничение памяти

--maxmemory-policy

noeviction

Поведение при достижении лимита: noeviction или политики вытеснения allkeys- / volatile- (полный список — в kividb --help)

--loglevel

info

debug, verbose, notice (или info), warning, nothing

--logfile <path>

стандартный вывод ошибок

Запись лога в файл

--log-format <text|json>

text

Формат строк лога

--io-model

auto

auto, uring или tokio (io_uring только для Linux)

--requirepass <password>

нет

Пароль для пользователя default

--aclfile <path>

нет

ACL-файл для загрузки пользователей

--replicaof <HOST> <PORT>

нет

Репликация с указанного первичного узла

--replica-announced-port <port>

порт сервера

Порт, объявляемый первичному узлу через REPLCONF listening-port

--slowlog-log-slower-than <us>

выкл.

Порог slowlog в микросекундах (0 — логировать каждую команду)

--slowlog-max-len <n>

128

Количество хранимых записей slowlog

--cluster-enabled <yes|no>

no

Режим кластера: шина кластера на <port> + 10000, топология в nodes.conf, gossip, обнаружение сбоев и failover

--cluster-node-timeout <ms>

15000

Время без ответа, после которого узел считается недоступным

--tls-port <port>

0 (выкл.)

TLS-листенер (только в сборках с TLS)

--tls-cert-file, --tls-key-file

нет

Сертификат и ключ сервера (PEM)

--tls-ca-cert-file

нет

CA для проверки клиентских сертификатов

--tls-auth-clients <yes|optional|no>

yes

Требовать ли от клиентов сертификат (только совместно с --tls-ca-cert-file)

--update-check <yes|no>

yes

Проверка обновлений при запуске

TLS

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: CA, подписавший cert.pem

Клиентские сертификаты (взаимный TLS, mTLS). При указании --tls-ca-cert-file ca.pem клиенты обязаны предъявить сертификат, подписанный этим CA; остальные будут отклонены на этапе handshake. --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-порту. Незашифрованное подключение к нему (например, redis-cli -p 6381 без --tls) не проходит handshake, а сервер записывает в лог [TLS] handshake failed. Для memtier_benchmark добавьте --tls (и --tls-skip-verify для самоподписанного сертификата).

Логи и ошибки

Лог пишется в стандартный вывод ошибок или в --logfile. Формат лога описан в docs/LOGGING.md; предупреждения, ошибки, ответы с ошибками и рекомендации по ним — в docs/ERRORS.md.

Проверка обновлений при запуске

При запуске релизная сборка KiviDB делает один HTTPS-запрос к https://github.com/kividbio/kividb/releases/latest — той самой странице, которую вы бы открыли для поиска новой версии. GitHub отвечает редиректом на тег нового релиза; если он новее запущенной сборки, KiviDB выводит краткое уведомление со ссылкой перед стартовым баннером. Передаётся только сам запрос с заголовком User-Agent: kividb/<version> — без имени хоста, конфигурации, ключей, данных или идентификатора. GitHub видит IP-адрес источника запроса, как любой веб-сервер.

Сервер ждёт ответа не более 1,5 секунды; сбой логируется только на уровне debug и никогда не влияет на клиентов. Из ответа принимается только тег в виде номера версии, ничего другого не выводится.

Отключить проверку можно любым из способов:

  • --update-check no в командной строке;

  • update-check no в файле конфигурации;

  • переменная окружения KIVIDB_NO_UPDATE_CHECK=1.

Проверка также не выполняется в debug-сборках и при установленной переменной окружения CI. --update-check-url перенаправляет запрос на другой https://-адрес, например на зеркало внутри закрытой сети. Подробности — в docs/UPDATE_CHECK.md.

Участие в разработке

Мы рады вкладу от сообщества. Как собирать, тестировать и отправлять изменения — описано в CONTRIBUTING.md. Вклад принимается в соответствии с Лицензионным соглашением участника (CLA), которое вы подписываете при первом pull request.

Пожалуйста, соблюдайте Кодекс поведения. Изменения в каждом релизе перечислены в Changelog.

Безопасность

Пожалуйста, не сообщайте об уязвимостях безопасности в публичных issues. Инструкции по конфиденциальному сообщению — в SECURITY.md.

Лицензия

Copyright (c) 2026 KIVIDB PRIVATE LIMITED.

KiviDB — программное обеспечение с открытым исходным кодом, распространяемое под лицензией GNU Affero General Public License версии 3 (AGPL-3.0-only), одобренной OSI. Вы можете использовать, изменять и распространять его в соответствии с её условиями. См. NOTICE.

Использование KiviDB не распространяет действие AGPL на ваше приложение. Приложение, взаимодействующее с KiviDB по сети через любой Redis-клиент, является отдельной программой: вы можете использовать немодифицированный KiviDB как базу данных в любом продукте — открытом или закрытом, коммерческом или некоммерческом — без каких-либо обязательств в отношении кода вашего приложения. AGPL предъявляет лишь одно требование сверх GPL: если вы модифицируете сам KiviDB и предоставляете другим доступ к изменённой версии по сети (например, как размещённый сервис), вы должны предложить им исходный код своего варианта KiviDB.

Коммерческая лицензия. KIVIDB PRIVATE LIMITED владеет авторскими правами на KiviDB и также предлагает его по коммерческой лицензии для организаций, которые не могут использовать программное обеспечение под AGPL или хотят изменять либо встраивать KiviDB без публикации своих изменений. Пишите на support@kividb.io.

Наше обязательство. Каждая версия KiviDB, выпущенная нами под AGPLv3, останется доступной под AGPLv3. Лицензионное соглашение участника позволяет нам предлагать коммерческую лицензию параллельно; оно не является способом отозвать открытую версию.

FAQ

  • Могу ли я использовать KiviDB как базу данных для своего закрытого или коммерческого приложения? Да. Ваше приложение подключается к KiviDB по сети и не является производным от KiviDB — AGPL не налагает на него никаких обязательств.

  • Могу ли я запустить KiviDB как сервис для своих пользователей или клиентов? Да. Если вы запускаете его без изменений, публиковать ничего не нужно. Если вы изменяете KiviDB и предоставляете изменённую версию через сеть, вы должны предложить её исходный код пользователям этого сервиса.

  • Считаются ли клиентские библиотеки или конфигурация модификациями? Нет. Redis-клиенты, файлы конфигурации, скрипты и функции, которые вы отправляете в KiviDB, не являются частью KiviDB.

  • Моя организация не разрешает использовать программное обеспечение под AGPL. Для этого случая существует коммерческая лицензия: support@kividb.io.

Товарные знаки

Redis® является зарегистрированным товарным знаком Redis Ltd. Все права на него принадлежат Redis Ltd. Любое использование этого знака KiviDB носит исключительно справочный характер и не означает какого-либо спонсорства, одобрения или аффилиации между Redis и KiviDB. KiviDB не связан с Redis Ltd. Прочие упомянутые названия являются товарными знаками их соответствующих владельцев.

Похожее

© 2026 meganuke