As deeply as you have time for. There is a lot of fluff these days about being "database agnostic", but unless you like the idea of lowest-common-denominator features defining your best efforts you need to know how your database works. You'll get better results on non-trivial projects if you decide to make your schema and database application agnostic instead of going the other direction.
The last sentence of the previous paragraph flies in the face of just about all Web-2.0 common knowledge. It is worth deciding where your project falls on the "Better is Better" VS "Worse is Better" continuum.
But this does not mean that you should just pick one database to learn about, and what I really mean is that you shouldn't just learn one data paradigm. While fully normalized relational schemas are your best bet for thoroughly understanding your data, they are not workable for many practical applications (but they make an excellent permanent data store from which you can build high-speed warehouses tailored to specific queries later on, if you have the resources). A deliberately denormalized relational schema is usually your backbone, but you often also need a graphing database and -- just as important as your normalized relational schema -- you will probably need to develop a serialization schema (think along the lines of YAML, not XML, btw -- data, not documents). If you do geographic or spatial data then a GIS-specialized data store can quickly become a must as well. Document databases can also become necessary if you realize one day that what you are doing (or, more realistically, some heavily-loaded aspect of what you are doing) is actually document storage and not record storage.
Having said all that, you will need to understand enough about each to write an intra-db integrity layer (which can be asynchronous, so don't panic) lest they not understand one another. This requires knowing how DBs work.
This sounds like a lot to know, but only because it is. Data is just that important. Sure, you can be like the Web 2.0 guys and kludge your way along... until you hit on a really novel idea and suddenly realize that you can't practically implement your cool idea. Data drives use, not the other way around, and these days its getting shorter and shorter shrift. Don't be the next person who saved a few weeks doing some genuine study of data modeling (in all its forms) only to spend a lifetime of reinventing a data management system that lives only within your one-off project.
It took me a long time to come to this opinion, and my evolution was slow. I didn't need all this knowledge at once; understanding data in a more complete way has come as a side effect of interacting with more interesting aspects of problems that emerged over time as I worked. (In particular, in the process of writing three very large business simulation systems by myself.)
EDIT: It is worth mentioning that the reason I gave special mention to the relational model is that it is possible to simulate any other data model with relational data, but not necessarily possible to simulate every other data model from all of the others. Normalized relational is the most general and therefore the place to start learning how databases and data models work (and these are related ideas with good databases like Postgres, DB2 and Oracle). But pure normalized relational can sometimes be like trying to build a skyscraper with a Swiss Army knife if adhered to religiously. That is why I say you should understand your data in a fully normalized relational way though you may not actually implement it in such a way (or even in a database at all).
In practical terms, if you learn relational data theory thoroughly first you will quickly grok the strengths and compromises inherent in non-relational systems (to include flavor-of-the-week systems) such as CouchDB, AllegroGraph, ObjectDB, etc. and exactly where ORM abstractions fail (IOW, you'll know exactly why 1 class != 1 table && 1 object != 1 row (not even remotely close)) and learn many new things about functional and imperative programming as well.