PeaDB is pre-1.0 and has not been through an independent security audit. Do not store data you cannot afford to lose, and do not expose an instance to an untrusted network, until you have reviewed the known gaps below against your own threat model. Open defects that can lose or change data are listed in compat/delta.md items 24–77.

Only the latest tagged release receives security fixes. There is no long-term support branch — upgrade to the newest tag to get a fix. See docs/RELEASING.md for how releases are tagged and published.

Please report privately through GitHub's advisory form rather than opening a public issue: https://github.com/alsatianco/peadb/security/advisories/new. You should receive an acknowledgement within 7 days. Please do not disclose the issue publicly until a fix has shipped.

These are verified facts about the current codebase, not a guess at what might be missing. Weigh each one against your deployment before you rely on PeaDB for sensitive data.

• No TLS. There is no TLS/SSL support anywhere in the server — zero references to TLS, SSL, or OpenSSL in src/, include/, or the build (CMakeLists.txt). Traffic between clients and PeaDB, and between a master and its replicas, is unencrypted. If you need encryption in transit, terminate TLS at a proxy in front of PeaDB (for example stunnel, Envoy, or your cloud load balancer's TLS listener) — do not rely on network trust alone for anything crossing an untrusted boundary. A config that turns TLS on (tls-port other than 0, tls-replication yes or tls-cluster yes), in a file or on the command line, stops startup with "Failed finding TLS support", as a Redis built without TLS does, so a ported TLS config cannot start a plaintext server by mistake; the other tls-* settings are accepted with a warning that they have no effect (compat/delta.md item 24).
• No multi-user ACL engine. PeaDB enforces a single default user's password (requirepass); there is no per-user rule engine, so you cannot scope one credential to a subset of keys, commands, or pub/sub channels. ACL SETUSER, DELUSER, LOAD, SAVE, and DRYRUN all refuse with an explicit error rather than silently accepting a rule they cannot enforce — a prior version of ACL SETUSER returned OK while discarding the rule, which is now fixed; the command tells you plainly that it did nothing. See compat/delta.md items 1 and 7 for the full detail.
• Some redis.conf hardening lines cannot be honoured, so they stop startup. A redis.conf that sets passwords with user default on >… lines or an aclfile makes PeaDB refuse to start, because it has no ACL users; set requirepass instead. loadmodule and enable-debug-command no also stop startup. Replication can authenticate to an enabled Redis ACL user using masteruser and masterauth (item 50); this does not add a local ACL engine to PeaDB. Other Redis settings that PeaDB does not apply yet are accepted with one warning for each in the log, so read the log after each config change (compat/delta.md item 24). rename-command <name> "" removes a command, as in Redis.
• No Sentinel. There is no SENTINEL command and no automatic-failover control plane. If you need automated master promotion, you must build it on top of REPLICAOF yourself, or run PeaDB behind an orchestrator that already owns that decision (Kubernetes or an equivalent).
• Cluster mode is experimental and not production-safe. PeaDB's Cluster reply shapes (MOVED/ASK redirects, CLUSTER SLOTS/SHARDS/NODES) are real, but the topology is operator-configured, not gossiped — there is no failure detector and no automatic failover, so a node going down does not cause another node to take over its slots. Routing checks only a command's first key, a restarted node serves slots that other nodes own, and a cluster-enabled replica drops replicated writes, so cluster mode can put data on the wrong node or lose it. See compat/delta.md items 6, 43 and 64–67 and the cluster addressing decision record.
• Weaker defaults and no audit trail. Existing DEBUG verbs are open to every authenticated client, where Redis 7.2.5 refuses it unless enable-debug-command is set; disable it with the config-file line rename-command DEBUG "" (enable-debug-command no stops startup, see above). The new DEBUG SEGFAULT requires explicit startup enable-debug-command yes and is refused by default. CLIENT SETINFO accepts spaces and newlines, so a client can change how CLIENT LIST output reads to tools that parse it, and the password compare can reveal the password's length through timing (compat/delta.md item 61). Failed logins leave no log line and no acl_access_denied_auth counter, and logs go only to stdout (item 60). The bundled Lua lacks the patches Redis applies to its copy, so script isolation relies only on PeaDB's Lua-level sandbox (item 62).

Given these gaps, treat TLS termination and multi-tenant isolation as the operator's responsibility: put a TLS-terminating proxy in front of every instance that crosses a network boundary you do not fully trust, and enforce tenant isolation (separate instances, network policies, or an orchestrator's namespace boundaries) rather than relying on PeaDB's own access control to separate tenants.

For the full, always-current compatibility and feature-status picture, see docs/compatibility.md and the canonical gap registry compat/delta.md — this file does not restate per-feature status that those documents already own.