Feature Description: When using multiverse-type server setups (i.e. more than one "map"-one overworld/nether/end) split the monolithic database into distinct, per-world or per-set (a set of the linked overworld+nether+end maps)

Additional context:

• I've been hosting a server for me and a group of friends for many years now, and my main point was the commitment to keeping previously played maps accessible either for nostalgia trips or for people unwilling to start fresh.
• That being said, an issue that has become more and more annoying, -especially when making backups- is the database slowly but surely ballooning in size as years pass and more maps are added.*
• I know this is unavoidable and expected, but backing up or moving a 55gb database when only one or two maps have any changes made to them seems very wasteful. I also know you can save them as individual images, but that is even MORE unwieldy as it makes an absurd amount of files if you use high quality renders and multiple zoom levels.
• That being said, i realized recently while making a VM virtual drive, that it offered the possibility to have it either as a single monolithic file or split into up to 4gb separate files. Adapting this to map renders, having them grouped per-world i feel would organically split the data into more logical chunks for the user to view and manage, and help prevent having to move around potentially gigantic files.*

I don't think it is that easy to split each world into their individual databases, as with the jdbc connector, as far as I have read, you need to specify the database, so each world would have their own connector, which is kinda wastefull. I don't know whether the connected database can be procedurally altered during runtime, but I am not a dev so just talking from my own experience with using the plugin. furthermore, within the database, in the maps table, each world / map has their own prefix, so you can split it that way, also, if still having the world, you can specify visibilitylimits, in where only certain parts of the world will get rendered, limmiting the overall filesize of the database. but indeed, it would be nice to have, just spilling my salt on the subject.

Then maybe some other format other than .db? I found this short forum thread which seems to be pretty much on point with our issue.

Alternatively something closer to the filetree storage (again not considering individual image tiles as a solution since it's the polar opposite of this issue)

Hm, maybe stitching textures into larger atlases and keeping them as large(r) images?

Hm, maybe stitching textures into larger atlases and keeping them as large(r) images?

tilesizes is a recent feature that should fix that, but the many small sizes was selected as an optimisation for browsers, as large big files can make the browser lagg.

union is indeed already used for tiles, but the dev @mikeprimm can tell you more about it once he has time.

Has there been any decision if this feature suggestion is worth/desired to be added in the foreseeable future? As time goes on and maps get bigger/new ones get added this issue gets more and more painful for an otherwise great plugin.