You can’t get a database of all such public keys, but you can get some of them.
An address, as you know, is a hash of a public key. When somebody sends coins to an address, you can think of the associated public key as having a positive balance, but nobody else necessarily knows what the public key actually is. (You can’t compute the public key directly from the address, because hash functions are effectively one way.)
However, in order to spend the coins from that address, the spending transaction has to reveal the public key (so that the spending transaction’s signature can be verified). So what you need to look for are addresses with a positive balance that have also had some coins spent. I am not aware of any simple way to do this short of making an index of all transactions. It is possible you could rig up a way to produce such a list by querying a fully-synced bitcoind using
-txindex (so that all transactions are indexed), but it seems likely to be inefficient.
But as a randomly chosen example, consider the address 1Q6NNpHM1pyh6kEqzinBhEgsRc3nmpTGLm. It is associated with some public key which has a balance of BTC 259.7299, but since (as of this writing) no coins have been spent from that address, nobody except the owner of the address knows what the public key is. So your database will necessarily be incomplete; probably very incomplete.
In particular, most people use a new address for each of their transactions (including change addresses), in which case the transaction that reveals the public key for an address also spends all its coins (so that the balance is now zero), and that public key will likely never be used again. This strategy is used partly because certain theoretical cryptographic attacks are easier if the public key is known, and this strategy mitigates the risk from such attacks; it also increases privacy by making it harder to look at patterns of transactions to try to deduce who the address belongs to.
Another case in which you can learn the public key is so-called P2PK transactions, where the output script includes the actual destination public key, instead of merely its associated address. These were common in the past, but these days all standard clients use the P2PKH transaction type, in which only the address is used.