For large volumes of data--I'm assuming large individual items--I'd use a subdirectory named for the parent pid, and files named by monotonic numbers for the items; and have the parent manage the item numbers and coordinate the pushes & pops via a socket.

If the parent already has a role to play beyond waiting for its kids, then it just requires one more fork for the socket manager.

When a child pushes an item, it sends a push message to the parent socket, and gets back a new item number, creates and writes the file.

When a child pops an item, it sends a pop message to the parent socket and gets back an item number which forms the name of the file it must read and delete.

If the items can persist across runs, or the parent crashes, you supply the name of the original pid directory that the new instance will take over, and it renames it after itself; scans the directory to discover the lowest/highest item numbers; opens its port and kicks off its kids with the port number.

Since any substantial volume of data sent to a DB is going to end up in the file system anyway, why funnel it all through a pipe or socket when the entire "data management" part of the equation consists of nothing more than coordinating the increments of two monotonically increasing numbers?