Disadvantages of geth's snap sync?

Question

I've been researching Ethereum execution clients and it seems (please do correct me if I'm wrong) that currently geth's snap sync is by far the fastest and most widely used.

So my question is, what are some disadvantages of using it (over full sync)? I've read the official blog posts and taken a look at its GitHub and the most obvious one seems to be the inability of a node that's synced with it to (easily) respond to historical questions dating before the pivot block, e.g. "What was X's balance a year ago?". Of course, for many users who are not block explorers, such a use might never be necessary.

Are there any more serious drawbacks to using snap sync? Perhaps any in terms of network security if we assume that most of the network's clients are using it? Since it still results in a full node as opposed to a light one I would assume not, in which case is there any practical reason for a new node that wants to join the Ethereum not to use geth's snap sync?

Answer 1

geth's snap sync is by far the fastest and most widely used.

true, since geth is a default client ("the winner take it all") and snap sync is a default option to sync

So my question is, what are some disadvantages of using it (over full sync)?

in full sync all transactions are executed within evm, with fast sync only headers are verified

Perhaps any in terms of network security if we assume that most of the network's clients are using it?

Snap sync is not supported by Erigon, OpenEthereum, and only supported in Nethermind since v1.13.0

is there any practical reason for a new node that wants to join the Ethereum not to use geth's snap sync?

since it's a default mode, it's unlikely that a node will use another syncing method