<p>I've ran tests before on .5 million addresses generated in one afternoon. It fired walletnotify within the milliseconds, no noticeable delay when I sent an amount to a random address. Only noticeable thing was that the client took 30 minutes to start up, which I guess is fine if you run a larger service. Only thing that may trouble you is slow transaction creation time, but someone on here advised me to just move the funds into a new address monthly.</p>

CC BY-SA 3.0
2013-12-29T21:44:27.107Z
How will it behave once you have multiple transactions involving all those addresses though? I guess the advice to move all the funds to a new address monthly is to solve that issue?
Emre K.
CC BY-SA 3.0
2013-12-29T22:46:06.780Z
Transaction size, and therefore fee, will become greater the more spread your funds are. Although I'd assume that moving them to a central address should solve it as a singular unspent output is created from many.
John T
CC BY-SA 3.0
2013-12-29T21:14:37.720Z
2013-12-29T21:14:37.720Z
John T
<p>I tested this by programatically adding 1 million addresses to the QT client via the JSON-RPC interface from a Java program. Rescanning was turned off so all it did was add the addresses and not confirm the balances. It took around 24 hrs to add 1 million addresses and then it took another 4 hrs or so to restart the client and scan the 1 million addresses. I was using a MacBook Air so not very powerful hardware. Still, given the amount of time it took to do the rescan I would not recommend using the QT client with that many addresses in a production setting. Good luck.</p>

CC BY-SA 3.0
2014-01-02T14:28:17.257Z
Your test might not be sufficient to predict what will happen in real life scenarios that involve millions of transactions and possibly hundreds of accounts in the wallet.
Emre K.
CC BY-SA 3.0
2013-12-30T15:49:30.887Z
2013-12-30T15:49:30.887Z
Chuck C.
<p>Regular BitcoinQT client is not suited to run a <em>huge</em> amount of addresses/transactions.
The database easly goes to the roof in a month with IO operations, if you do, let's say, 1 transaction per minute. 
Please consider reading blockchain directly, or use external service, which will handle the overhead for you, ie. Blockchain.info</p>

CC BY-SA 3.0
2013-12-29T21:46:57.197Z
Assuming we use outside service for walletnotify and blocknotify on the addresses we keep in our wallet. (Like adding them as a watch only address) Won't the client still pull transaction data related to our addresses from the network? And therefore have the db go to the roof again?
Emre K.
CC BY-SA 3.0
2013-12-29T21:10:53.040Z
2013-12-29T21:10:53.040Z
Maciej Mączko
<p>We use the standard client in our business. The wallet already contains about 25k addresses. Will the wallet remain stable after the number reaches 100k or a million addresses? I was told that all major business have forked the client. Should we also fork and code our own wallet?</p>

CC BY-SA 3.0
2013-12-29T21:25:30.610Z
Related: [How to handle a ridiculous amount of receiving addresses](http://bitcoin.stackexchange.com/q/19331/5406)
Murch
<bitcoind><client><scalability>
Does the original Bitcoin client scale to contain millions of addresses?
Emre K.
# Does the original Bitcoin client scale to contain millions of addresses?

(Asked by: username_0 on 2013-12-29)

We use the standard client in our business. The wallet already contains about 25k addresses. Will the wallet remain stable after the number reaches 100k or a million addresses? I was told that all major business have forked the client. Should we also fork and code our own wallet?

**Tags:** bitcoind, client, scalability

> **Comments:**
> **username_1**: Related: [How to handle a ridiculous amount of receiving addresses](http://bitcoin.stackexchange.com/q/19331/5406)  

---

## 3 answers

### Answer by username_2 on 2013-12-29. Score: 5

I've ran tests before on .5 million addresses generated in one afternoon. It fired walletnotify within the milliseconds, no noticeable delay when I sent an amount to a random address. Only noticeable thing was that the client took 30 minutes to start up, which I guess is fine if you run a larger service. Only thing that may trouble you is slow transaction creation time, but someone on here advised me to just move the funds into a new address monthly.

> **Comments:**
> **username_0**: How will it behave once you have multiple transactions involving all those addresses though? I guess the advice to move all the funds to a new address monthly is to solve that issue?  
> **username_2**: Transaction size, and therefore fee, will become greater the more spread your funds are. Although I'd assume that moving them to a central address should solve it as a singular unspent output is created from many.  

---

### Answer by username_3 on 2013-12-30. Score: 3

I tested this by programatically adding 1 million addresses to the QT client via the JSON-RPC interface from a Java program. Rescanning was turned off so all it did was add the addresses and not confirm the balances. It took around 24 hrs to add 1 million addresses and then it took another 4 hrs or so to restart the client and scan the 1 million addresses. I was using a MacBook Air so not very powerful hardware. Still, given the amount of time it took to do the rescan I would not recommend using the QT client with that many addresses in a production setting. Good luck.

> **Comments:**
> **username_0**: Your test might not be sufficient to predict what will happen in real life scenarios that involve millions of transactions and possibly hundreds of accounts in the wallet.  

---

### Answer by username_4 on 2013-12-29. Score: 3

Regular BitcoinQT client is not suited to run a *huge* amount of addresses/transactions.
The database easly goes to the roof in a month with IO operations, if you do, let's say, 1 transaction per minute.
Please consider reading blockchain directly, or use external service, which will handle the overhead for you, ie. Blockchain.info

> **Comments:**
> **username_0**: Assuming we use outside service for walletnotify and blocknotify on the addresses we keep in our wallet. (Like adding them as a watch only address) Won't the client still pull transaction data related to our addresses from the network? And therefore have the db go to the roof again?  

---

