I think you've jumped far too quickly into the design stage of the electronics portion that you now do understand better and have given short shrift (by waving hands in the air) to studying the SD card specification. You should shift gears and set aside the easier part (which is the electronics that simply flows out of the information you still need to collect) and delve more deeply into the SD card portion of this.
Study the specification. Look, for example, at 126.96.36.199. What times do you see there? Have you read 4.4 and looked at going into energy saving modes for the SD card? If you are doing a write, will you also need to do a read prior to that? (Are you partially modifying a block?)
If you are planning on using the Arduino library without understanding the code that was written for it and how it relates to the SD card specification, first hand, then you need a way to make measurements with the library so that you can observe what it actually does do and what the power requirements look like.
In the best of circumstances, you should at least read the SD card specification for the relevant parts of what you are trying to do. Not necessarily because you are going to write code -- it seems you want to use the library code -- but because you need to understand the specification itself to know what your library must contend with. This allows you to anticipate circumstances that 1000 measurements of actual tests won't tell you about. You can test all day long with the library and never trip up on some detail. So you'll just go and assume, figuring that since you haven't seen a problem, there won't be a problem later on.
This is the point of reading the SD card specification, as a matter of independently informing yourself and not just blindly using a library. Sure, the author probably read the specification and does know these things. But when they create the library, they don't document everything they've learned. They just write the library. You have the job, separately, of knowing the specification and the reach of it in cases where you can't actually test. (It's impossible for you to go get every SD card ever manufactured. But if you read the specification, you can make sure that you cover all the conforming cards and situations, at least.)
There's no escaping your education here. You can focus on what you care about: Write, Power Saving Mode, Read (perhaps), and anything else you can think up that you might do (or you think the library actually will do.) But to design the electronics which is responsible for maintaining sufficient power, you need to know just how long the worst case might be. And you need to know that, firmly, in your own head and to to exactly why you know what you know. You could be able to rattle it off almost as fast as you can talk.
Once you have a full handle on that part, and assuming your library does its job as it should, then you can make some estimates. But really, the electronics part of this is almost trivial. Falls out so easy. The difficulty is all the rest here and making sure you know what the worst case might be. With that, the electronics design just falls out.
For example, from Section 188.8.131.52:
For a Standard Capacity SD Memory Card, the times after which a
timeout condition for write operations occurs are (card independent)
either 100 times longer than the typical program times for these
operations given below or 250 ms (the lower of the two).
While the card should try to maintain that busy indication of write
operation does not exceed 250ms in the case of SDXC card, if the card
is not possible to maintain operations with 250ms busy, the card can
indicate write busy up to 500ms including single and multiple block
write in the following scenarios:
- a) The last busy in any write operation up to 500ms including single and multiple block write.
- b) When multiple block write is stopped by CMD12, the busy from the response of CMD12 is up to 500ms.
- c) When multiple block write is stopped by CMD23, the busy after the last data block is up to 500ms.
- d) Busy indication at block gap in multiple block write is up to 250ms except a following case. When the card executes consecutive two
blocks write (2*512Bytes) and it spans across the physical block
boundary, the busy after the each block can be indicated up to 500ms.
Especially regardless of the above definition, a speed class writing
mode specified by CMD20 shall keep write busy up to 250ms in any case
until the end of speed class write is indicated.
Or this, as one of their final notes:
It is strongly recommended for hosts to implement more than 500ms
timeout value even if the card indicates the 250ms maximum busy
What do you make of all the above, for example?
Here's another interesting note (to me) that seems to relate a corner case to your desire for 512 byte writes. From Section 4.4:
For example, in the case that a host with 512 Bytes of data buffer
would like to transfer data to a card with 1 KByte write blocks. So,
to preserve a continuous data transfer, from the card's point of view,
the clock to the card shall be stopped after the first 512 Bytes. Then
the host will fill its internal buffer with another 512 Bytes. After
the second half of the write block is ready in the host, it will
continue the data transfer to the card by re-starting the clock
supply. In such a way, the card does not recognize any interruptions
in the data transfer.
From this, I have learned that not all SD cards use 512 byte blocks. That's interesting. It makes me wonder if the Arduino library supports this mode of lower power operation. And it makes me wonder if you should perhaps consider writing your own code, as this could actually be helpful when performing writes and wanting to lower overall power consumption.
What do you think?
Just searching the web for others who have wanted to keep times short when writing to an SD card, I did find the following comment you might want to consider -- not as fact, but as motivation for you to work harder in understanding what's ahead of you.
The comment was (found here):
Reading the specifications, it should "typically" take 0.5 ms to write
a block, with a worst case of 240 ms. What I find is a rather steady
100 ms. If I can't reduce this, it would burn a lot of power and
require a re-design for bigger batteries.
The writer of this, above, did appear to have read the specification, as they noted the 240 ms worst case (which is, as we can now read, actually 250 ms.) So that adds some credibility to the question and to the note about what they are actually finding, in practice, as well.
It's one data point, of course. But it should provide some motivation for you to really knuckle down and understand what the SD card specification allows.