Migration of large amount of data - worried about `node` overhead and performance

I need to write a quick web frontend for an existing gui app that just displays information about a large quantity of image data; this data is in a myslq db currently. I would like to use Drupal if I can.

The image data model would work fine translated as nodes, I am just worried about query performance due to the overhead of storing this data as nodes; there will be 250K and a million images.

Additionally affecting performance, I believe I will need to use two content types for each image - one for static data (ex. 'name'), one for dynamic data (project-specific stuff), with a nodereference from static to most recent revision of the dynamic.
However, the traffic will not be high at all, maybe 50 users, and I have a decent 2U server with lots of ram and a T1.

Is it worth it for me to put a migration scheme into place to script the existing data into the drupal db as nodes, or should I just write a web service to connect to the existing database and not use drupal's content system at all (just use it for it's infrastructure, and spit the query results into $page or whatever)? Or is Drupal not suited for this at all, and I should go learn django and stop bothering you? ;)

As I write this, I realize that my question could be distilled into this:
"Will drupal's stable infrastructure, caching, and ease of development make up for the overhead that the content system will create when a huge amount of data is mapped/stuffed into a non-simplistic content type structure?"

On a side note, I wonder, now that Drupal is gaining popularity, if some ORM code will pop up to help people use Drupal in this manner.

Thanks for your help!