Recenty I have been asked:
"Does Magnolia require a separate database for non-content data?"
Well, what is non-content? In the philosophy of JSR-170 "everything is content".
Technically, everything is accessed through the JSR-170 API, which is very well specified and the documentation is well written. The API is implemented by various implementations (well), Jackrabbit, CRX, Oracle 11 (and FileNet I believe) being the most prominent and useful ones. We are repository agnostic, ship with Jackrabbit but strive to support all mature repository implementations on the market to provide choice to our clients.
Jackrabbit in turn has a persistence layer which abstracts the act of persisting content from they way it is done. This allows a number of brilliant persistence options - from using JDBC to access "any" database, specific adapters to specific databases to in-memory persistence (in fact, no persistence), which is massively useful for test and development environments, because the state of the repository can be exquisitely well defined in a snap, before tests are performed, and take much less time, since they are in-memory.
Finally, to get closer to the question, the various methods of accessing databases may allow a partitioning of the content that is stored. Certainly Oracle has many switches to slice and dice your data to your hearts content. More prominently even is the BerkleyDB (now also owned by Oracle) persistence adapter that allows you to define if blobs are stored inside the database or directly on the file system.
In any case, none of this makes any difference of how you access the content from within Magnolia, herein lies the beauty of it all. Combine this with the fact that Magnolia is repository-agnostic and allows you to use "activation" to move any content from one Magnolia instance to a second one (or several at once), you can start in any way you like, perform tests, set up another instance with a different configuration or database and activate your content to this instance, then repeat the tests.
This is the freedom Magnolia provides at the storage level, a freedom that allows our clients to match their requirements using any independent storage solutions out there today, instead of locking them into a proprietary repository, like just about every other CMS on the market does today, including other prominent open source players.