{{< warning title="Deprecated" >}} Yugabyte's current focus is on the two distributed SQL APIs, namely [YSQL](../api/ysql/) (PostgreSQL-compatible fully-relational API) and [YCQL](../api/ycql/) (a semi-relational API with Cassandra QL roots). **Given that YEDIS is not a focus, it must be viewed as a deprecated API for new application development purposes.** {{< /warning >}} The YEDIS API allows YugabyteDB to function as a persistent, resilient, auto-sharded, globally-distributed key-value database that is compatible with the Redis command library. A Redis client can connect, send requests, and receive results from this API. {{< note title="Redis compatibility" >}} While YEDIS supports many Redis data types (such as string, hash, set, sorted set, and a new time series type) and commands, there are some notable exceptions: * Only a subset of sorted set commands (ZCARD, ZADD, ZRANGEBYSCORE, ZREM, ZRANGE, ZREVRANGE, ZSCORE) have been implemented. Several commands like ZCOUNT, ZREVRANGEBYSCORE, ZRANK, ZREVRANK are not implemented. * List, Bitmaps, HyperLogLogs, and GeoSpatial types/commands are not implemented. * YugabyteDB is a full-featured disk-based database and does not have an in-memory only architecture like Redis. YEDIS is not a drop-in replacement to an existing Redis app. For key-value workloads that need persistence, elasticity and fault tolerance, [YCQL](../api/ycql/) (with features like keyspaces, tables, role-based access control, and more) is often a great fit, especially if the application is new rather than an existing one already written in Redis. The [YCQL drivers](/stable/develop/drivers-orms/) are also more clustering aware in terms of routing the request directly to the node which hosts the row/key, and hence YCQL even performs marginally better than YEDIS for equivalent scenarios. In general, our new feature development (support for data types, built-ins, TLS, backups, and more), correctness testing (using Jepsen, for example) and performance work is in the YSQL and YCQL areas. {{< /note >}}