I am using Btrfs.
Btrfs inode limits is in a whole different league (whereas ext4's inodes are allocated at filesystem creation time and cannot be resized after creation, typically at 1-2 million, with a hard limit of 4 billion, btrfs's inodes are dynamically allocated as needed, and the hard limit is 2^64, around 18.4 quintillion.
> -- https://unix.stackexchange.com/questions/18388/what-are-the-...
I haven't seen anything but ext4 or xfs in over a decade
nice to know it still exists :)
Use a better file system with the ability to "scale up".
Attempting to predict and set an arbitrary limit on the max. number of files at the time of creation is an unnecessarily hamstrung and self limiting design.
This is particularly egregious in an era of constantly increasing storage demands, volume capacities and drive pooling in an OS promoted for it's server prowess and flexibility.
It becomes a problem when you: (1) scale up (2) have to deal with multiple relationships between objects. The "Database design" by Adrienne Watt posted in another comment covers the scale concerns well, but another scale problem she doesn't mention is hitting inode limit, at least if you're on a single machine. You can of course use a distributed filesystem as database, but at that point, you might want to use a database proper.