How to shard 14 gb of data for archival database? We have 14 GB worth of CSV's containing product information, with each CSV being all the records for a US state.  We now want to store this in a database.  There would be ~130 million records.

The data only needs to be written once.  No new data will be added to this database.  It will be read from ~10 times per hour.  Almost all of the queries will use one indexed field.  We're looking for a response time under 5 seconds.

Would MySQL be appropriate for this, and if so, what is the minimum amount of RAM you would think the server needs?  Should it be sharded by state?  If not MySQL, what other options do we have?
Any full featured database will be able to handle this with ease. My preference would be for Postgres, however SQL server, Oracle and MySQL are all valid options.

When designing the tables you need to consider how you will read the data so that you can optimize read performance. There are a couple of things to look at.

1> Appropriate indexes for the queries you are going to run.
2> The use of Partitioning (read the appropriate manuals). You would use partitioning in this case perhaps by having a partition per state assuming the queries that need to perform affect only one state's data at a time.
3> Disk and network.  These can often be the cause of slow reads so make sure that they are as fast as you can afford.  Consider if you need to have a RAID type replication or can live without this.  i.e.: do you need 100% up-time [RAID] or can you afford to have some downtime [single disk and backup] if there is a disk failure.
4> If you have a choice of storage methods with the chosen DB, choose the most appropriate t the task at hand. Again refer to the DB's documentation for advice.
5> Maintenance plan. Ensure you regularly rebuild fragmented indexes and tables, this will help prevent slowing performance over time.  

When it comes to RAM, get as much as you can fit into the server you have.