RUM uses several databases. First there is the MySQL database that is part of the RUM engine. This database holds clickstream data and snapshots, as well as page hits and such. Only summary data is sent up to the BAC DBs in bus samples. Examining the RUM sample definitions will demonstrate what data goes from the engine up to BAC. This database keeps two weeks of data by default and every 5 days it runs a job to clean out old data. These times can be configured and there is good info on this in the RUM PDF. It's always a good idea to run the RUM MySQL db on a separate server than the engine. If you are working on a RUM implementation that combines the engine and database on the same server, find out why. It's probably affecting performance.
Next is the BAC profile database. This is where the samples that are sent from the engine are stored.
RUM stores information about defined apps, pages, user groups, etc. in the BAC management database. These tables all start with RUM_ and when you synchronize in the RUM admin interface, this is the database that is sync'd.
RUM also uses the CMDB for reports, where BPM reports do not. So if you have a problem with RUM reports and not BPM reports, it could be an issue with the CMDB. It's a lot more likely there is a problem with RUM reports though. Today we uncoverd an issue where RUM reports take longer and longer to generate, even selecting filters takes a long time if there are a number of defined applications. The more apps you define, the more time it takes to generate RUM reports.