The MANIFEST file contains history of all file operations of the DB since the last time DB was opened, and is replayed during DB open. If there are too many updates to replay, it takes a long time. This can happen when:

• SST files were too small so file operations were too frequently. If this is the case, try to solve the small SST file problem. Maybe memtable is flushed too often, which generates small L0 files, or target file size is too small so that compaction generates small files. You can try to adjust the configuration accordingly

If your memtable size is large, the replay can be long. So try to shrink the memtable size.

When options.max_open_files is set to , during DB open, all the SST files will be opened, with their footer and metadata blocks to be read. This is random reads from disk. If you have a lot of files and a relatively high latency device, especially spinning disks, those random reads can take a long time. Two options can help mitigate the problem:

• options.max_file_opening_threads allows reading those files in parallel. Making this number higher usually works well on high bandwidth devices, like SSD.
• Set options.skip_stats_update_on_db_open=false. This allows RocksDB to do one fewer read per file.

Some users manage multiple DBs per service and open DBs one-by-one. If they have multi-core server, they can use a thread pool and open those DBs in parallel.