this depends on how the alpha data affects the beta element count. But if this statement is true, then there is no way around having separate and delayed allocations.
You should practically never need to calculate every possible combination to get an upper bound, there is almost certainly a worse case at most points of contention.
allocation does not always mean a syscall, the OS provides somewhat large chunks (usually 4kb), called pages, at a time; allocators will try to reuse it as much as practical, there are exceptions since zig supporting custom allocators which result in speciality ones such as page_allocator which does do a syscall every time, other allocators typically build on top of it.
I would like to point out, that while an upper bound is ideal, a reasonable bound should also be considered. Defaulting to an upper bound is not optimal if it is rare and large.
For example, zig allocates 80% (i think) of source file size for tokens or ast (cant remember) as that cathes the majority of code, but it does allow growth for the rare case that needs more than that.