There are many specialised products for HF tick data. In addition to KDB which you mentioned, there is OneTick, Vertica, Infobright, and some open-source ones like MonetDB etc. (see http://en.wikipedia.org/wiki/Column-oriented_DBMS).
My experience is that Column Oriented Databases are overrated when it comes to tick data, because very often you request the entire tick or bar record (as opposed to just one column of a record - i.e. what Column-Oriented DBs are optimised for). In my experience, the key to speed is much more that you use a clustered index for your database, thus defining the order in which the data is stored on the harddisk. If you primarily query the timeseries of a given instrument (as opposed to the latest prices of a group of instruments), then you want to cluster by (Instrument, TickTimestamp), making queries extremely fast even for huge table sizes.
Then there is also the school of thought that plays around with new alternatives out of the NoSQL corner, such as BigTable, MongoDB, etc. It's an interesting area, but my personal believe is that they are made primarily for flexible datamodels, which is not our core requirement. You can make them work, and they'll work very fast, but this comes at the cost of more archaic tool support, steeper learning curves, etc.
I have been using many different databases (Oracle, MySQL, SQLServer, MongoDB, MonetDB) over the years, and my conclusion is that most of them work pretty decently for storing financial timeseries data if you understand them and design them accordingly. Currently, I'm using primarily SQLServer, which is somewhat faster than MySQL, free for smaller datasets, and does most of the things I want. Support for R (and Matlab and many other environments) is very decent through the ODBC R package.