That's a tiny amount of data. I agree that a database would be overkill. (Although I disagree with your reasoning. If you need to perform searches across hundreds of thousands of items, Access will be orders of magnitude faster than anything you could build with StreamReader/StreamWriter. The main problem with a database engine is the startup costs. And in this case, the startup costs are going to be much bigger than the total volume of data you need to deal with... So it's not worth it in this case. It's misguided to write off OLEDB as slow though - for the scenarios it's designed for it's extremely quick.)
I just wrote a simple test to see how long it takes to write out an entire file of the size you're discussing. I had 8 lines of 8 strings each, a total file size of 928 bytes. Writing the file to disk repeatedly over 10 seconds, it was taking about 1ms to write the whole file.
That's a small fraction of the blink of an eye. Do you really need to spend time optimizing this? I suspect your efforts could more usefully be directed elsewhere.
Most of the cost of small disk IO is in the seek time - it takes several milliseconds to move the disk read/write head into the correct location. So the only reason my test was as fast as it was is because it was repeatedly overwriting the same file - it was writing in the same place every time. In particular, the test demonstrates that you're at the point of diminishing returns - the time it takes to write the file out itself is going to be an order of magnitude smaller than the average time it would normally take the system to get to the point where it's able to begin writing.
So even if you were able to speed up the actual writing to disk by a factor of 10 (and that's not a realistic goal, for reasons I'm about to explain), it'll make no difference in the usual case. You say you only write the file occasionally, so normally, the disk head is unlikely to be in the right place at the point at which you write the file. This means you'll pay the seek and settle costs every time. Those are about 10ms. So your typical timing will be 10ms + 1ms using the brute force approach - 10ms to get the disk ready to write, and 1ms to write - that's 11ms. If you speed up the disk writing by a factor of 10, that makes no difference to the seek or settle times, so you're now at 10ms + 0.1ms - 10.1 ms. In fact, even if you were to optimize writing to the point where it was infinitely fast, you've still got a cost of 10ms to pay... So the best you can ever hope to achieve is about a 10% improvement. And since 10ms is only a fraction of a blink of an eye, a 10% improvement on that will not be something the end used will notice.
In any case, you won't be able to speed things up all that much. You can ask the system to modify just a single byte on disk, but in practice it will always write back one entire sector at a time. Disks don't have the ability to write one byte at a time. So in practice you'll be writing 512 bytes of data back. (Or whatever your sector size is. 512 is a common size.)
The approach you are proposing only becomes worthwhile once the size of the file is significantly larger than the size of a sector. For a 1MB file there's a big difference between writing the whole thing out and changing one part. But for a 1KB file, the difference is so small that you probably won't even be able to demonstrate a difference. So why bother?
But if you insist on adding significant complication for negligable benefit...well as I said before, you need to use FileStream. You can call Seek to tell it which bit of the file you're interested in and then Write to write some bytes. It's all byte oriented - it has to be, because 'text' is not an abstraction that's all that amenable to random access, for the reasons I discussed before. So you need to do your own encoding. But frankly, it's not going to be worth the effort for the volumes of data you're talking about.
