First of all, are you sure you really need that? Have you calculated the memory footprint?
A small back-of-the-envelope calculation: A single mob and its state should fit into 100 byte of data. Let's give it a whole kByte, in case you are doing something extraordinary. When a cell has 1000 such entities, it requires a MByte. If your world is 100x100 cells, you would need 10 GByte of RAM. That's a lot, but still within a reasonable order of magnitude. The hoster where I hosted my last multiplayer project offers servers with up to 768 GB of RAM. And that's still not the limit of what's technically possible RAM-wise (if you have a deep budget). But I am just inventing numbers here. You should have much better data about the planned size of your world, its entity density, the memory footprint of each entity and the memory footprint you need for any other features of your game.
But let's say that you did the math on your own and come to the conclusion that the memory footprint will be too much for the kind of server you budgeted for. So you indeed have to get that memory footprint down. In that case you can save a lot of memory by only having those cells in memory which have active players and storing the data of all others on the hard drive.
When you have areas without any online characters in them, suspend that area by persisting the state of all entities to hard drive and removing it from memory. You can store that data in a database or by inventing your own file format.
When a player enters a suspended area, reload it from file/database and initialize all entities according to the suspended data. If you have any timed processes which are supposed to continue even when there is no player nearby (like regrowth of resources), determine how much time elapsed since the cell was suspended and simulate that time accordingly.