I know PiAware runs mainly from memory, think this is to avoid too much writing to the microSD card.
The aircraft data created by dump1090 - is this temporarily stored then uploaded to FA, FR24 etc every so often, is it then retained or disposed of? Do FA and FR24 receive the same data or is there a separate uploader working for each installed feed?
Geoff
ADS-B data is never stored on the sd-card, no matter the feed client or receiver i can think of.
Micro sd-card problems are almost never due to excessive writes but due another type of failure.
I doubt your problems were due to excessive amounts of data written.
Anyhow the amount of data written at which the sd-card will not like it, scales with sd-card size.
I’d just buy one of those, they are cheap, really big, and fast:
https://www.amazon.com/dp/B06XX29S9Q
(Note the 32 GB version is slower but of course also more than sufficient)
If you insist on reducing writes, which i don’t think is necessary at all, you can do this:
GitHub - wiedehopf/graphs1090: Graphs for readsb / dump1090-fa / dump1090 (based on dump1090-tools by mutability)
Even log files are mostly not written to the sd-card.
I’m not sure about that though, that depends a bit on the Raspbian version i believe.
FlightAware & FR24 have different upload mechanisms.
piaware runs faup1090 which listens to the raw message stream from dump1090 and tracks aircraft state (it shares much of the dump1090 code for that); periodically a summary of changes for each aircraft is uploaded. So there is some temporary storage, but it’s on the order of 30 seconds or so and it is purely in memory. The relevant code is here: dump1090/net_io.c at 61f483c3e766aef8747893780da00c3c8e06b654 · flightaware/dump1090 · GitHub
The equivalent FR24 uploader is closed source, so no idea what it does.
Haven’t currently got any problems with SD card, did last week but that all resolved.
Geoff
This is great, if it can reduce writes from 100MB per hour to 10MB per hour then my microSD card can last 100 years, think of the money I can save 
Geffers
As obj already stated, the uploaders are different and each will filter the data differently before sending it off to the servers.
What is common though is the datasource if you are using dump1090-fa for example.
That will put out beast-data on 30005 which all feeders will connect to without the connection ever leaving the computer. (local loopback)
The opensky and adsb-exchange datafeeders just forward that beast data directly to their servers.
Obviously those use quite a bit more bandwidth, aound 25 kB/s for 1600 messages/s.
FA bandwidth depends less on message rate but more on how many aircraft you have in view.
Typically 1-2 kB/s i would guess.
FR24 is in that same ballpark, but that depends a lot on how many other feeders are picking up the same aircraft.
Once a few receivers of theirs receive an aircraft, they tell the other receivers not to send ANY data bout that aircraft. At least that’s what the log looks like, as obj said it’s closed source.
Then separately the MLAT process uses some more bandwidth than mentioned above.
It should stay well below the bandwidth of 25 kB/s for all messages though, maybe half or a quarter of that.
Depends on the mlat client and number of mlat aircraft.
Strange, wonder why FR24’s uploader is closed source.
Ah well, it all works, just nice to know what is actually going on, quite fascinating actually.
Being fairly close to Heathrow, London, with just an indoor aerial I can see the aircraft on Skyview on a Heathrow flightpath from about 20 miles away, They often pass over my house at 8000 feet. If the wind is different then the take offs pass over at around same altitude, bit louder though
Geoff
Thanks for interesting reply.
Geoff