The memory limit is not physical memory, it is the fact that you can only address 4 GB with a 32-bit pointer.

BerkeleyDB might solve this by taking less memory. It might also be able to use anonymous paging to work even though it cannot directly address most of that memory. The documentation says that data sets that large usually speed up by switching from hashing to a BTREE.

But letting it swap won't work.

I read the problem. You can only address 4GB of physical memory, but you can use more in swap if you run Linux with PAE (Page Address Extensions), as available in Red Hat's "Advanced Server" distribution. There may be something similar for other OSes.

Note that I have not used this and can't speak about it from experience. My situation was with a process going over 2GB on a FreeBSD machine with 2GB of physical RAM.

PAE lets the OS and specifically aware processes address more memory than what a simple pointer can address. If you turn it on then your OS can use more memory. That doesn't let any individual application push the 32-bit limit unless the OS supplies hooks for mapping and unmapping memory into what the program can directly address, and the program is aware of and uses those hooks.

If you had a single process address over 4 GB of RAM on a 32-bit CPU, then the OS has to provide those hooks and the application has to be using it. It would make sense for BerkeleyDB to try this, but I don't know if does. If it doesn't and you want it to, you could pay Sleepycat to develop it for you.