I will keep my clothes on, thank you very much! I might bear with you being bare, though. 
When you say MMORPG, what kind of gameplay do you mean? Do you mean the kind where there are “zones” and players teleport between them? Or do you mean a large, seamless world? How dense a player population do you need to build?
In general, a MMORPG or virtual world will have three to five tiers in architecture. The simplest system, used by original EverQuest etc, uses a single game server per zone (much like a big FPS game,) and has code that runs on the servers talking to a database using that database’s API (libmysql for the MySQL database, etc.) It is important that the player clients do not talk directly to the database, for security reasons – standard SQL server access controls and performance characteristics are wholly inadequate for exposing to the greater Internet. So, the tiers are client -> server -> DB.
Some systems need to better manage players, and put some kind of gateway in front of the game servers. This may allow them to do things like automatic load balancing, interest management, semi-seamless zoning, etc. That would be another tier, in front of the game servers. If you’re building an “indie” MMO game, you do not need this and it will just complicate things. The tiers are client -> gateway -> server -> DB.
Some systems use more business logic than just simple database inserts/updates. Those systems add an application server between the game server and the database. The application server takes simpler commands from the game servers, and translates them to business logic, which in turn talks to the databases and other back-end systems (payment processors, etc.) The tiers are client -> (optional gateway) -> server -> app server -> DB.
Regarding Kyp’s suggestion to use file I/O for storing things server side, that may work OK for small prototype implementations, but it really will bite you hard as soon as you try to run a robust full-time operation. If you don’t want to use SQL servers, you can look into alternative data stores, like Redis, Cassandra, or some graph database. Or, if you are hosting your servers “in the cloud,” look at SimpleDB, BigTable, and friends.
Now, having answered your question (“use libmysql for Linux, or SQL Server for Windows”) I will also give you another observation: MMO games are large, complex, distributed systems. If you don’t already have at least some experience in that area, you are pretty much doomed to technical failure, unless you get some solid experience on board. Note that you need someone who knows all three of web-type architecture, IT-type architecture, and game-type architecture, to make it come out successful. Someone who only knows one of those three is unlikely to pick the right tool for each job.
Another tought that comes to me is that creating an MMO requires a lot more content than “just” a regular game of the same kind, and a RPG requires more content than, say, an FPS. Thus, if you are in the “indie” situation, you may also be looking at a project that’s too big for the team you have. Without knowing more about your situation, It’s impossible to tell for sure, of course.