Most of the time what's notable is obs, which if not explicitly set uses bs, which if not explicitly set generally defaults to 512. So, quite depends what one is writing, but, e.g. for most files on most filesystems these days, [o]bs=4096 would be an appropriate minimum, and should generally use powers of 2 to avoid block misalignment and problems/inefficiencies thereof. If writing directly to a drive, most notably solid state rather than hard drive, generally best to pick something fair bit larger - the larger of either erase block size or physical write block size - so that would typically be the erase block size that would be larger. If unsure, an ample power of 2, e.g. [o]bs=1048576 will generally quite suffice.

wouldn't I just set bs=500m ?

No, not only not well aligned, but that's going to be eating almost half a gig of RAM and won't be that efficient, it may well want to buffer that full amount before writing out same, and if it's not multi-threaded that's likely also to be pretty inefficient and slow, as it switches back and forth between such long large reads, and then writes. Much better would generally be a much smaller but ample block size, e.g. in the range of a suitable power of 2 between 4096 and 1048576, and that will likely also be much more efficient - swallow up a whole lot less RAM, and as the writes will generally be buffered, will typically be switching back and forth between reads and writes pretty quickly and efficiently, and mostly only limited by I/O speeds - so probably by whatever's slower, the reads, or (often) the writes (depending on media type, etc.). With much large/excessive bs, buffers/caches will fill on the writes, so one will typically spend most of the time waiting on I/O on the writes, but it will be inefficient, as with also such large reads, same will happen on the read side, while the write side goes idle.

And if you're writing, say, e.g. to device that's RAID-0 or RAID-10 or RAID-5 across multiple drives, you'll want integral multiple of whatever size covers an entire "stripe", e.g. say you have 5 drives configured as RAID-5, so that's 4 data + 1 (distributed) parity. You'll want integral multiple (minimum multiplier of 1) to whatever fully covers those 4 chunks of data - so you write that, and all that and the parity is calculated and written in one go - if you do less than that at best you'll be recalculating and rewriting at least one data chunk and the parity data multiple times, likewise if you're not an integral multiple of that size. When in doubt, pick something that's "large enough" to cover it, but not excessive.

If you're dealing with particularly huge devices, may be good to test some partial runs first. But note also that buffering may make at least initial bits appear artificially fast. One may use suitable (if available) dd sync option(s) and/or wait for completion of sync && sync after dd, and include that in one's timing, to be sure one waits for all the data to be flushed out to media, and to be sure one includes that in one's timings.

So, yeah, [o]bs does make a difference. Pick a decent clueful one for optimal, or at least good, efficiency.