Ok, so the best analogy is: a database is a warehouse. Every user has a shelf in this warehouse, and they add and take stuff to it at random. The workers in the warehouse move stuff in and out of the doors as orders (user requests) come in and out.

You can build the warehouse taller and wider to hold more shelves (vertical scaling of hardware), but only to a point before the forklift trucks can’t reach and driving across the warehouse for one order would take too long.
You can similarly add more workers (CPU power) and more doors (faster storage/memory) to your warehouse to handle more orders at one time, but these also have limits because the warehouse is only so big. And there’s eventually a point where no amount of workers or doors or shelf space will improve throughput, because the roads around the warehouse are clogged with trucks.

At this point the obvious solution is horizontal scaling- build a new warehouse somewhere else nearby, and a small office building (load balancer) that directs new orders to each of the warehouses evenly. Then you have the office occasionally check in with both warehouses to make sure they both have the same stuff to fulfill any given order (synchronizing instances). And as orders continue to increase, you can just keep adding more and more horizontal warehouses- all of which are individually somewhat small and simple, but effectively infinitely scalable compared to the vertical mega-warehouse we tried to build originally.

Lemmy tries to build in the horizontalness by having separate instances federate and share data automatically without the need for that “front office”. However the issue still stands that individual instances are going to need to handle hundreds of thousands of users for the Lemmy ecosystem to really thrive, and that is going to take a ton of back end database engineering to allow individual instances to scale as well as the fediverse network as a whole.