A "simple" DB like SQLite probably suits your purpose better than a huge in-memory hash table

• Re: Fastest way to lookup a point in a set - external databases were found to be "spectacularly much slower" than native Perl hashes
• Re: Bidirectional lookup algorithm? (Updated: further info.) - BrowserUk found hashes (and Judy arrays) to be about 30 times faster than SQLite

Note that in High Performance Game of Life (and related Fastest way to lookup a point in a set) profiling indicated that the millions of hash lookups required by the simple GOL algorithm was the dominant performance hot spot ... and the overhead of calling out to (external) SQLite for these was an order of magnitude slower than native Perl hash lookups (so long as you have enough physical memory to comfortably hold the hashes).

Buk comment: "however fast the C/C++ DB code is, calling into it from Perl adds a layer of unavoidable overhead that Perl's built-in hashes do not have"

I think that we need to learn more about the OP's application.
I said "probably", not for sure.
If the hash table won't fit into memory, then we have to do something else.

Nowadays, many home PCs (including mine) have 32 GB of memory and a 64-bit OS ...

-- from The 10**21 Problem (Part 2) (2014)

Agreed. Given the OP was "hoping to be able to go to at least 8GB" -- and given I had 32 GB of memory on my home PC way back in 2014 (and I am definitely not a rich man :) -- the simplest and cheapest something else may be simply "buy more memory". Well, that seems attractive for a commercial company because the cost of PC hardware is dwarfed by the cost of people (and the cost/risk associated with making massive code changes to critical production systems).