External Process vs. Threads and data processing

I'm working on a mmorpg game server that serves hundreds, sometimes thousands of players simultaneously. Some player actions sent to this server requires database access (sql), for example: when the user selects one of his characters, all data (items, levels, position) associated with this character are retrieved from the sql server even though this application doesn't have any (direct) connection with the the sql server. The software does this by sending an specific packet to an external data server that acts like a "proxy" to the sql server. (all of this done to avoid blocking the network thread pool with slow database queries)

To illustrate how it works:

Notes: each client has an ID, assume that the client is already authenticated and on the character selection screen.

1. [Player] sends a (packet) to the [GameServer] containing the selected character name.


2. [GameServer] sends a (packet) to the [DataServer] containing the (player id + character name)


3. [DataServer] executes all the required queries and sends a (packet) containing the requester id and all the character information to the [GameServer]


4. [GameServer] replies to the [Client] with the returned information (the DataServer sends the client id back to identify the client)

In sequence:

[Client] -> (character name) -> [GameServer] -> (player id + character name) -> [DataServer] -> (player id + character info) -> [GameServer] -> (character info) -> [Client]

This is how the whole architecture works today. But for me this is getting too complex to maintain because I have to maintain two separate softwares, and deal with network connections between theses servers and all the related stuff of creating new requests, new responses, parsing those, etc etc. I was discussing this with a co-worker and he said that an external server will perform better, but I was thinking about doing this using C++ features (lambdas), so I thought about creating a thread pool that each thread has its own database connection. This thread pool will waiting for database work to arrive (as std::function<> calls) so I can process the request easier and inside the same process, and without having to worry about blocking the network queue (iocp).

So, what is the pros and cons about using a thread pool on the same process instead of using an external process? Should I expect it to perform better, worse, or exactly the same?