wallet.dat – Is it safe to share wallet files between multiple Bitcoin Core instances using the new wallet DB technology?

There are setups where a single stateful Bitcoin node (with a read-only wallet) is no longer sufficient due to single points of failure and increased request load. As a result, you will need to run multiple Bitcoin server instances.

About 6.5 years ago, this question stated that it was not possible to share wallet.dat files between multiple Bitcoin servers due to the risk of wallet corruption and potential loss of funds. In particular, Ava Chow noted:

“You should not share the wallet.dat file between two servers. It may not work and may result in wallet corruption and loss of funds. If two instances plan to open the same wallet file, this is not acceptable. In BDB (Bitcoin Core) The database system you use does not allow multiple software to open the database at the same time, and if they somehow manage to do so, your wallet may be compromised.

Additionally, even if you don’t access your wallet files at the same time, the two nodes may be in different sync states, which can confuse the software and require it to be re-scanned each time you start one of the nodes. There may be other problems.”

The Bitcoin Core 26.0 release notes state:

“The createwallet RPC no longer creates legacy (BDB) wallets when you do not provide the -deprecatedrpc=create_bdb option and set descriptors=false. This is because legacy wallets will be deprecated in a future release.”

With changes in wallet DB technology, is it now possible to securely share one or more wallet files between multiple Bitcoin instances, ensuring that changes made on one server are reflected on the other without being corrupted? Will the new wallet technology support this use case, or will it still have the same limitations as the existing BDB wallet?

If wallet file sharing is still not allowed, what is the recommended way to scale a stateful Bitcoin Core setup (including wallets) to handle increased load and avoid single points of failure?

Thanks for your insight.