Even if you could do it, 10000 ports would be 10000 connections lets say.
You'll be getting transactions, tx requests and sync status updates from 10000 nodes, to which you HAVE to reply or you lose you connection (and thus possibly an endorsement). Aside from thrashing the crap out of the DB you'll need a big fat pipe.
In our tests a node connected to 8 others at 100+ tx/s load is processing about 250KB/s downstream and about 120KB/s up. Divide that by 8 and multiply by 10000 = 150,000KB/s or 1.2Gbits upstream.
So you need a machine that can handle potentially millions of DB requests per second, and a pipe that can handle over 1.2Gbits upstream and at least double downstream. Or are those things trivially cheap too?
Not really - I'd just have one grunt process for all the DB reads/writes and then pipe/queue/cache all the external network requests from the other processes, because having multiple databases is totally redundant in this case... after all it's just one machine.
Hmm Im not convinced you'd be able to get the performance required to the DB even with the most exotic of caching/read and write tricks. You could maybe memdb it, but then you need a hefty amount of RAM, which again costs.
Has anyone actually tried to benchmark 10000 "nodes" reading and writing to a single DB on decent commodity hardware, let alone the high end stuff? I don't think it would be very pretty.
Plus, what about the pipe, thats a hefty pipe you'd need to serve up 10000 nodes.