{ "schema_version": 2, "id": "commands/lmove", "title": "LMOVE", "url": "https://redis.io/docs/latest/commands/lmove/", "summary": "Returns an element after popping it from one list and pushing it to another. Deletes the list if the last element was moved.", "since": "6.2.0", "tags": [ "docs", "develop", "stack", "oss", "rs", "rc", "oss", "kubernetes", "clients" ], "last_updated": "2026-09-18T09:47:41+01:00", "page_type": "content", "content_hash": "a8c0f747e0d4f0cb6cd9a9881490d955741c44ce624e96e771124a8695e0f02e", "sections": [ { "id": "overview", "title": "Overview", "role": "overview", "text": "> [!NOTE]\n> This command's behavior varies in clustered Redis environments. See the [multi-key operations](https://redis.io/docs/latest/develop/using-commands/multi-key-operations) page for more information.\n\n\nAtomically returns and removes the first/last element (head/tail depending on\nthe `wherefrom` argument) of the list stored at `source`, and pushes the\nelement at the first/last element (head/tail depending on the `whereto`\nargument) of the list stored at `destination`.\n\nFor example: consider `source` holding the list `a,b,c`, and `destination`\nholding the list `x,y,z`.\nExecuting `LMOVE source destination RIGHT LEFT` results in `source` holding\n`a,b` and `destination` holding `c,x,y,z`.\n\nIf `source` does not exist, the value `nil` is returned and no operation is\nperformed.\nIf `source` and `destination` are the same, the operation is equivalent to\nremoving the first/last element from the list and pushing it as first/last\nelement of the list, so it can be considered as a list rotation command (or a\nno-op if `wherefrom` is the same as `whereto`).\n\nThis command comes in place of the now deprecated [`RPOPLPUSH`](https://redis.io/docs/latest/commands/rpoplpush). Doing\n`LMOVE RIGHT LEFT` is equivalent." }, { "id": "required-arguments", "title": "Required arguments", "role": "content", "text": "
source\n\nThe key of the source list.\n\n
\n\n
destination\n\nThe key of the destination list.\n\n
\n\n
LEFT | RIGHT\n\nThe end of `source` to pop the element from: `LEFT` (head) or `RIGHT` (tail).\n\n
\n\n
LEFT | RIGHT\n\nThe end of `destination` to push the element to: `LEFT` (head) or `RIGHT` (tail).\n\n
" }, { "id": "examples", "title": "Examples", "role": "example", "text": "redis> RPUSH mylist \"one\"\n(integer) 1\nredis> RPUSH mylist \"two\"\n(integer) 2\nredis> RPUSH mylist \"three\"\n(integer) 3\nredis> LMOVE mylist myotherlist RIGHT LEFT\n\"three\"\nredis> LMOVE mylist myotherlist LEFT RIGHT\n\"one\"\nredis> LRANGE mylist 0 -1\n1) \"two\"\nredis> LRANGE myotherlist 0 -1\n1) \"three\"\n2) \"one\"" }, { "id": "details", "title": "Details", "role": "content", "text": "" }, { "id": "pattern-reliable-queue", "title": "Pattern: reliable queue", "role": "content", "text": "Redis is often used as a messaging server to implement processing of background\njobs or other kinds of messaging tasks.\nA simple form of queue is often obtained pushing values into a list in the\nproducer side, and waiting for this values in the consumer side using [`RPOP`](https://redis.io/docs/latest/commands/rpop)\n(using polling), or [`BRPOP`](https://redis.io/docs/latest/commands/brpop) if the client is better served by a blocking\noperation.\n\nHowever in this context the obtained queue is not _reliable_ as messages can\nbe lost, for example in the case there is a network problem or if the consumer\ncrashes just after the message is received but it is still to process.\n\n`LMOVE` (or [`BLMOVE`](https://redis.io/docs/latest/commands/blmove) for the blocking variant) offers a way to avoid\nthis problem: the consumer fetches the message and at the same time pushes it\ninto a _processing_ list.\nIt will use the [`LREM`](https://redis.io/docs/latest/commands/lrem) command in order to remove the message from the\n_processing_ list once the message has been processed.\n\nAn additional client may monitor the _processing_ list for items that remain\nthere for too much time, and will push those timed out items into the queue\nagain if needed." }, { "id": "pattern-circular-list", "title": "Pattern: circular list", "role": "content", "text": "Using `LMOVE` with the same source and destination key, a client can visit\nall the elements of an N-elements list, one after the other, in O(N) without\ntransferring the full list from the server to the client using a single [`LRANGE`](https://redis.io/docs/latest/commands/lrange)\noperation.\n\nThe above pattern works even in the following conditions:\n\n* There are multiple clients rotating the list: they'll fetch different\n elements, until all the elements of the list are visited, and the process\n restarts.\n* Even if other clients are actively pushing new items at the end of the list.\n\nThe above makes it very simple to implement a system where a set of items must\nbe processed by N workers continuously as fast as possible.\nAn example is a monitoring system that must check that a set of web sites are\nreachable, with the smallest delay possible, using a number of parallel workers.\n\nNote that this implementation of workers is trivially scalable and reliable,\nbecause even if a message is lost the item is still in the queue and will be\nprocessed at the next iteration." }, { "id": "redis-software-and-redis-cloud-compatibility", "title": "Redis Software and Redis Cloud compatibility", "role": "content", "text": "| Redis
Software | Redis
Cloud | Notes |\n|:----------------------|:-----------------|:------|\n| ✅ Standard
✅ Active-Active | ✅ Standard
✅ Active-Active | |" }, { "id": "return-information", "title": "Return information", "role": "returns", "text": "**RESP2:**\n\n[Bulk string reply](../../develop/reference/protocol-spec#bulk-strings): the element being popped and pushed.\n\n**RESP3:**\n\n[Bulk string reply](../../develop/reference/protocol-spec#bulk-strings): the element being popped and pushed." } ], "examples": [] }