Various games store things in different ways. Often, game companies create some way to do this, and most of their games use the same way. Of course, different studios often use different ways. SQL is certainly used for games, e.g. CCP (EVE) has (or at least had) a network of SQL servers, I am not sure how they do it now. Others, just use lots of files.
Maybe start by creating an agnostic "data broker mechanism", to handle various game data transactions? Since you are just testing anyways, create a mechanism that enables you to not need to care too much about the storage, from a standpoint of the game itself. Meaning, concentrate on how, from the host application, you are going to handle this.
Personally I think it would be a great asset if you could switch the actual store, without having to rewrite the game and the broker itself. Just switch to another module with the same interface for the broker to talk to.
Storing data in itself is likely not going to be an issue, per se. Efficiently shipping data, to/from that store, between host and all the clients, could be trickier. Do I ship the entire player data set, or if I break it down into parts, what granularity do I choose to partition by, etc. Which one is more resource intensive in which situation, etc.
One format to ship the data in, could be XML. That way you can more easily be dynamic in how it you can chunk it up. One character vs multiple characters, or one item vs a collection of items, etc. You could then either "store" the XML as XML (in SQL), and/or have SQL distribute it in a more transactional fashion from the XML, to how you want the data actually stored.
Another way is binary, which is more efficient in terms of shipping, but can incur more cost in other situations.
With 1,000 clients, you could start with, and easily store 10 MB per client and only use 10 GB of effective RAM + add some system administrative RAM for managing that data, say another GB or two. You could keep that in RAM on the host already in data structure ready for use. And load/save dynamically, depending on who is online, in various frequencies depending on activity, etc.
You could even store each client's information in a separate file, and so on.