SSD disks are cheep these days but they don't like repeated writes/deletes so it might cause problems down the line (hence my first RAM recommendation)
as for keeping the raw data - you could easily do it if you use partitions, if you have daily partitions inheriting from a master table you can quickly access the last day (or even several days) but do take note that a full table scan takes time and you'll need to manage writing to the right partition yourself (not that hard - simply insert to <tablename>_<date>)
if you can write the data daily, keeping it will not add any real load (a little on parse times for queries that access the master table)
Interesting, you seem a lot less fussed by these numbers than I am, which is good to hear!
At what point does postgres stop scaling? What happens when the computational load no longer fits on one machine? What are the options then?
I think it is hard to come up with blanket responses to generic questions such as "What happens when the computational load no longer fits on one machine?"
I'd say consider a scaling strategy that may be able to make use of your domain model first, if that is possible of course.
I work in healthcare and patient centric records let me consider multiple servers for lots and lots of patients. The engineering team from instagram has been sharing their experience with postgres, which is possible due to their domain model.
So my humble suggestion is: start from the simplest scenario, ask yourself if you can use multiple, independent postgres installations, if your domain model and its data model allow you to do this. If not, you may still have other options, but it all depends on your access patterns etc.