The only thing you really need to understand about databases is that they store data for you, ie. they persist data. So once you get that then you start asking questions like "where" and "how".

The "where" is on hard drives. Don't let anyone tell you that a purely memory resident data store is a database, it's not. It's a cache. If you aren't writing to disk you are not a persistent database. Think memcached and redis. Although I would say the later is more of a database because you can configure it to write on every update.

The "how" is where all the devilish details are. How do you put data into and get data out of a database. How does the database store your data on disk. Well, there are two main schools of thought in the market place at the moment. Relational[0] and non-relational. Relational is the older more mature, more well supported, more well understood, more "standards" compliant of the two. Nowadays, non-relational is championed by the NoSQL[1] movement which eschews the relational model for a looser concept, less defined, less "compliant", less understood model. You will find many more and varied answers to "how" in the non-relational space precisely because the renaissance in non-relational is so fresh (the concept itself has been around a long time). Nevertheless, NoSQL has been attracting considerable attention over the last year or so in the open source community.

Every developer worth his salt will know or at least be familiar with the relational model and at least one or two of it's implementations. MySQL, PostgreSQL and SQLite are just three of the most popular open source RDBMS's (relational database management system)[2] around today. They all have varying degrees of support for the primary language used to speak to RDBMS's, SQL[3].

There are many open source, non-relational implementations in production today. HBase, Cassandra, Riak, Voldemort and MongoDB are all playing in the NoSQL field. Popular systems within NoSQL draw their lineage from either the Google approach (gfs[4], big table[5]) or the Amazon approach (dynamo[6]). Yet another is Neo4j, a graph database[7] which, at the moment, is lumped under the "NoSQL" moniker but is a separate beast entirely. Just like their relational cousins, the way NoSQL solutions do what they do and what they are best suited for vary.

As with most interesting discussions, which approach is best is left as an exercise for the reader. I'll just throw my two cents in for good measure. First I would say that you need to know SQL. Knowing SQL and not a specific system (like mysql or postgresql) will allow you to move in between relational systems and let you pick the right one for the job. After taking a look and familiarizing yourself with the SQL world, I would take a very serious look at what is going on with NoSQL. Best I can tell, there is a lot of mindshare and "cool" factor foisted upon this space right now because of the scale non-relational concepts can bring to enterprise users. Be sure, though, that rdbms is the predominant player in the database world. Every company large and small use some form of rdbms. Newer more forward looking companies that have large and very large scale needs to store and analyze vast quantities of unstructured or loosely structured data are looking more and more to non-relational NoSQL solutions.

I specifically avoid linking to particular implementations but rather link to broader concepts here. It is the concept that is more important than the implementation when learning about the big and confusing world of databases.

[0] http://en.wikipedia.org/wiki/Relational_model
[1] http://en.wikipedia.org/wiki/NoSQL
[2] http://en.wikipedia.org/wiki/Relational_database_management_...
[3] http://en.wikipedia.org/wiki/SQL
[4] http://en.wikipedia.org/wiki/Google_File_System
[5] http://en.wikipedia.org/wiki/Big_table
[6] http://en.wikipedia.org/wiki/Dynamo_(storage_system)
[7] http://en.wikipedia.org/wiki/Graph_database