Q:

What kind of databases are usually used in an MMORPG? 

Do people write their own DB for some reason? 

A:

We did, hopefully Ben Z will give a better explanation of the reasons than I can since he was actually the original author of our database.  The short version is that relational DBs are not very useful for games because they cannot efficiently store heavily structured hierarchical data, which makes up the vast majority of data an MMO needs for normal operation.  We choose to build a custom object database and part of a distributed transaction processing system, which is now in production and powering our two live games. 
As for if you should do the same?  Probably not, at least not at first.  I would still advocate avoiding SQL, but there are now many more options in the "NoSQL" world that didn't exist a few years ago. 
That said, most MMOs do run on SQL (relational) databases.  I know Eve runs on a SQL Server installation sitting on top of a few multi-TB RAMSANs (I will probably never in my life have as much money as those things cost). 
EDIT: Hopefully he won't mind me posting this here, but this is a blog entry with some links and comments about the presentation we gave at GDC'08 about our database. 

A:

Okay this answer is more of an observation.  
Full disclosure I haven't worked on MMORPG.  I have worked at what was one of the top 10 most visited sites back in 2009, and I have worked at game engine company that thought they were making MMORPG tech (I don't know if shipped). 
If you look at companies that have achieved massive scale (Google, Facebook, Twitter, etc.,  I know they are not game companies, but they are worth looking at in this space) there are two things that I think are important. 

They started by grabbing whatever was cheap and easy to get themselves going
They ultimately had to roll a lot of their tech on their own. ( And sometimes hardware)

A big mistake is to grab some expensive turnkey thing and expect it magically scale for you.  It doesn't work that way.  The key to scaling up is dealing with each new challenge appropriately.  You need flexible easy to use solutions that you can move in and out easily.  
So my advice to you would be if your starting out, just get what seems least headache to deal with.  

A:

Basically, there's a whole range of approaches, and I think they're chosen based more on the experiences of their developers as much as the properties of the database. 
At one end, many MMOs are using standard relational databases - eg.  Dark Ages of Camelot used/uses (are they still going?)  MySQL, FreeRealms use a modified Postgresql, etc. 
Moving along the scale, you have Guild Wars: they use SQL Server, but they stick their data in there as a single BLOB.  This means they get the benefits of their usual binary formats with some of the benefits that a database provides.  Needless to say, you can probably see some disadvantages of this approach too, but for a company used to working with flat files, it's probably still a step up. 
Then there are probably some places using the various formalised NoSQL approaches, although it's still early days yet.  Farmville uses membase, which they made for the purpose, based on memcached apparently.  This shares many features with the likes of MongoDB, CouchDB, etc.  Again with these approaches you're typically rolling your own storage formats but get the benefits of distribution, caching, redundancy, etc. 
Some are rolling their own NoSQL entirely: Cryptic said they did something similar but also said they weren't using it in production. ( EDIT: but see comments below.) 
And then you come to people who are using flat text or binary files - as I understand it the older games like Ultima Online, Everquest, etc all went down this route, and for a company with game development experience but little database experience this works well too. 
Note also that you almost never get around writing your own database in some loose sense of the term - in games you'll always have bespoke data that you need to manage either in-memory or on-disk in ways that don't lend themselves to generic software.  You can't do SQL queries every time you want some data so you will need to be mirroring a lot of your information in the code no matter what back end you use.