That works beautifully if I want to partition the shared memory up into several buckets and reference each bucket by its index. However, assuming the DB is made up of differently sized information, I must either pick a bucket size big enough to store anything (and waste space on smaller things) or I allocate dynamically sized buckets and pass around pointers (as indexes no longer work).

Essentially, I was thinking I could create a version of malloc that operated within a shared memory region and then use it to allocate items in the DB dynamically to be stored in a chained hash table.

The "performance hit" on pointers is that I need to store the "pointer" to the bucket that I allocated (via my malloc routine) in shared memory somehow. Either that pointer is a native pointer into shared memory, or it is an offset into shared memory that every time application code goes to access a pointer it'll need to perform a conversion routine against it to acquire its position independant address. This would be required for either the array or non-native pointer methods. I guess I could tell the application (in the non-native pointer method) that the shared memory is a huge array of characters and access pointers through an "index" into the character array cast to the appropriate data type...but this seems just as ugly.

Maybe creating an intermediate "malloc" library against a shared memory segment is silly...but I don't know of a better way to store various dynamically sized data into any memory segment without wasting space on static sized buckets.