Cort Ammon's answer says
multi-level page tables [let] us be a bit more efficient, keeping pages only for regions of the address space that we are actually using.
and gnasher729's answer says
1 GB of page table could handle 512 GB of address space.
I think they both overlooked, or at least didn't make clear, an important point: the page table only contains the virtual-to-physical address mapping for pages that have a physical address. Its size is therefore a function of the amount of physical RAM in use, not the amount of virtual address space in use.
For example, if you have 8 GB of RAM and you mmap a 10-terabyte file, the OS most likely won't modify the page table at all at first; it will just record information about the mapping in some other private data structure. That data structure doesn't need to have an entry for every page of virtual address space covered by the file. It may be an interval tree in which the entry for the whole file takes just a few tens of bytes.
Later, when the user process tries to access a part of the mmapped file, the CPU will find no page table entry for the virtual address and will generate a page fault. The OS's page-fault handler will look up the virtual address, find that it's backed by the disk file, and start the process of reading a portion of the file into physical RAM. After the read completes, it will update the page table and restart the faulting instruction.
The user process may eventually read the entire 10 terabytes of data, but long before it finishes doing that, the OS will have started evicting earlier pages from RAM to make room for new ones. When the pages are evicted, the corresponding entries in the page table can also be freed. So the page table never grows to 10 TB / page_size * entry_size. Its size is closer to 8 GB / page_size * entry_size.
Also not mentioned in other answers is that the virtual address isn't stored in the page table entry. The table is indexed by the virtual address, so it's coded implicitly by position. With a 40-bit address bus and 212-byte pages, each leaf entry only needs to contain the high 28 bits of the physical address and some metadata like write and execute permission bits.
In a comment, Nate Eldredge said
When actual memory is large, another way of reducing the memory needed for page tables is to allow for larger pages. x86 has an option to mix 4 KiB pages with 2/4 MiB pages.
As far as I know, the motivation for large pages is to save time, not space. CPUs since the earliest days of paging have had a specialized cache for page table entries, the TLB. This cache isn't very large, and misses require an expensive lookup in the in-RAM page table. If the pages are 512 times larger then it's like your TLB has 512 times more entries.
Larger pages do save page table space, but the overhead for 4K pages is already only 0.2% assuming a 8-byte entry size. Large pages also waste space to coarser allocation granularity.