- Fallback method which is sure to always work, as it is virtually the same as getting all the blockchain data you'd get from another node, but in one single file.
- It's lighter because it doesn't have any overhead for indexing etc.
- It can be appended to easily when new data is available.
- Slower, because the daemon needs to verify all the data, the same as it would do when getting blocks one by one from the connected nodes.
- Also, if you keep both LMDB and the .raw on the same drive, the performance impact will be amplified as the same drive will be used for read/write and it can't do both operations at the same time.
In the past, the LMDB database format was not compatible across platforms. This is an optimized storage built with performance and robustness in mind, to allow the wallet to quickly access and use the data it needs.
On the other hand, the .raw file is "raw" as the name implies, meaning it should be platform-agnostic, ie, the data inside is the bare minimum, unoptimized, blockchain data, as it flies over the network, and nothing else. Think of it as just copying and pasting block data one on top of another and saving this into a file. The .raw file, then, is just a collection of all the blocks in the correct sequence.
When importing, the wallet needs to check it for consistency, by validating each block in the .raw file against concensus rules, because it can't know whether it had been constructed in the correct way, so it needs to check the signatures, PoW etc., unless you exported the .raw yourself or got it from a trusted source.