The flash chip is broken up into sections called erase blocks. On a 4M chip it's usually 64k and on an 8M chip it's 128k. Each erase block is rated at about 100,000-1,000,000 erase/write cycles depending on vendor.
This just means that on a 4M chip you have to have to erase 64k and rewrite it even if you only want to change one byte of the 64k. After that 64k block has been erased 100,000 times you risk failure where it won't store the data properly.
The problem with the NVRAM implementation is that it's exactly one erase block at the very end of the flash. When you boot, the NVRAM data is copied to a buffer in ram; with the exception of "nvram commit", all the nvram commands are using the copy in ram. When you do an "nvram commit" it writes the contents of ram to the flash. So, when you have a chip rated for 100,000 cycles, you'll probably have a failure around the 100,000th "nvram commit".
Most firmwares are based on the concept that if you change a setting it commits the change to nvram and reboots the router, and that every page has an "apply" button. If I want to change two settings which are on different pages, it will commit and reboot twice (while dropping open connections both times).
OpenWrt implements a writable filesystem using jffs2. There are are three important features of jffs2:
- data is compressed
- it's journaled
- it has wear leveling
The only feature which matters in this discussion is the wear leveling. Suppose we have a jffs2 filesystem with two types of files, files that never change and files that change frequently. Common sense says that the erase blocks containing the files that never change or contain free space will only be written once and will remain untouched while the blocks containing the other files will change frequently; wear leveling means that all of the blocks within the jffs2 filesystem will be used equally, so all of the blocks in the above example would be written to equally even if it means moving data that hasn't changed.
So in answer to your question yes, you could probably do it fine with jffs provided that your database wasn't too busy. I'd still recommend using usb since it's easier to replace a broken usb stick than a broken flash chip.