128 partitions is the default limit for GPT, and it's probably painful in practice to use half that many...
Linux itself originally also had some limitations in its device namespace. For /dev/sdX it assumes no more than 15 partitions (sda is 8,0, sdb is 8,16, etc.). If there are more partitions, they will be represented using 259,X aka Block Extended Major.
You could certainly still do more partitions in various ways. Loop devices, LVM, or even GPT inside GPT. Sometimes this happens naturally when handing partitions as block devices to virtual machines, they see the partition as virtual disk drive and partition that.
Just don't expect such partitions inside partitions to be picked up automatically.
As @fpmurphy1 pointed out in the comments, I was wrong: You can change the limit, using gdisk, expert menu, resize partition table. This can also be done for existing partition tables, provided there is unpartitioned space (a 512-byte sector for 4 additional partition entries) at the start and end of the drive. However I'm not sure how widely supported this is; there doesn't seem to be an option for it in parted or other partitioners I've tried.
And the highest limit you can set with gdisk seems to be 65536 but it's bugged:
Expert command (? for help): s Current partition table size is 128. Enter new size (4 up, default 128): 65536 Value out of range
And then...
Expert command (? for help): s Current partition table size is 128. Enter new size (4 up, default 128): 65535 Adjusting GPT size from 65535 to 65536 to fill the sector Expert command (? for help): s Current partition table size is 65536.
Eeeh? Whatever you say.
But try to save that partition table and gdisk is stuck in a loop for several minutes.
Expert command (? for help): w --- gdisk gets stuck here --- PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 22253 root 20 0 24004 11932 3680 R 100.0 0.1 1:03.47 gdisk --- unstuck several minutes later --- Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING PARTITIONS!! Do you want to proceed? (Y/N): Your option? (Y/N): y OK; writing new GUID partition table (GPT) to /dev/loop0. Warning: The kernel is still using the old partition table. The new table will be used at the next reboot or after you run partprobe(8) or kpartx(8) The operation has completed successfully.
And here's what parted has to say about the successfully completed operation:
# parted /dev/loop0 print free Backtrace has 8 calls on stack: 8: /usr/lib64/libparted.so.2(ped_assert+0x45) [0x7f7e780181f5] 7: /usr/lib64/libparted.so.2(+0x24d5e) [0x7f7e7802fd5e] 6: /usr/lib64/libparted.so.2(ped_disk_new+0x49) [0x7f7e7801d179] 5: parted() [0x40722e] 4: parted(non_interactive_mode+0x92) [0x40ccd2] 3: parted(main+0x1102) [0x405f52] 2: /lib64/libc.so.6(__libc_start_main+0xf1) [0x7f7e777ec1e1] 1: parted(_start+0x2a) [0x40610a] You found a bug in GNU Parted! Here's what you have to do: Don't panic! The bug has most likely not affected any of your data. Help us to fix this bug by doing the following: Check whether the bug has already been fixed by checking the last version of GNU Parted that you can find at: http://ftp.gnu.org/gnu/parted/ Please check this version prior to bug reporting. If this has not been fixed yet or if you don't know how to check, please visit the GNU Parted website: http://www.gnu.org/software/parted for further information. Your report should contain the version of this release (3.2) along with the error message below, the output of parted DEVICE unit co print unit s print and the following history of commands you entered. Also include any additional information about your setup you consider important. Assertion (gpt_disk_data->entry_count <= 8192) at gpt.c:793 in function _parse_header() failed. Aborted
So parted refuses to work with GPT that has more than 8192 partition entries. Nobody ever does that, so it has to be corrupt, right?
This is what happens when you don't stick to defaults.