Different SD cards have different write latency. Some cards are much faster than others.
I recently wrote a continuous 44.1 kHz, 16 bit recording to SD example on Teensy 3.1. It was necessary to queue up incoming audio while the SD card writes.
Regarding a specific link, here's that code, with lines that can be uncommented to view the actual write latency:
Now, I realize most of you probably don't have a Teensy 3.1 to actually run this code. Since I don't want Grumpy Mike to say I'm not replying with a helpful response, I ran it just now with those 2 lines uncommented.
Here's a representative chunk of the output printed to the Arduino Serial Monitor:
SD write, us=1476
SD write, us=1475
SD write, us=10692
SD write, us=7370
SD write, us=6812
SD write, us=1437
SD write, us=1427
SD write, us=1430
SD write, us=1447
SD write, us=1435
SD write, us=1457
Virtually all the writes are under 1.5 ms. Quite often, one write takes about 7 ms, and on rare occasions, a sequence of 2 or 3 writes takes about 8 to 10 ms. I believe the 7 ms ones correspond to writing 2 blocks, one data and the other to update the FAT table. I do now know why some take 10 ms, but it very likely could be internal block allocation inside the SD card.
In this example, Teensy 3.1 is recording a mono, 16 bit stream at 44.1 kHz sample rate. In this example, Teensy 3.1 has a pool of 60 buffers, each capable of storing 128 samples, which is about 174 ms of audio.... much more than necessary to deal with the 10 ms latency, or groups of 2-3 such writes.
Arduino Uno might have slightly higher latency, since the SD library would use a slower SPI clock. But let's neglect that, and assume buffering for approx 25 ms is enough to handle the worst SD write latency.
At a slow 8000 Hz sample rate, that's only 200 samples of buffering. That's very easily achievable on Arduino Uno. You could allocate about 1000 byes for a buffer where an ADC interrupt would store the incoming samples (assuming they're 8 bits each - discarding the low 2 bits from the ADC). The main program could give that data to the SD library, which has another 512 byte buffer. It may be a squeeze to get everything else to fit into Uno's limited memory, but I'm sure it could be done.
Of course, a lower-level approach that wrote directly to the RAW sectors on the SD card could have the ADC interrupt put the incoming bytes into either of two 512 byte buffers, and code could write either of those directly to the card without the FAT filesystem overhead. Even if the card stalls for 25 ms to complete a write, you'd be less than half full on the other buffer (ADC interrupt filling it while the main program waits on the SD card) and be ready to write it when full. Or you could expand to 3 such buffers, still within Arduino Uno's limited RAM, which might be necessary with lower quality SD cards. But if you use a good quality card (I tested a SanDisk Ultra), so much buffering should not be needed at only 8000 Hz sample rate.