Well, writes are definitely slower than reads. This is especially bad with writes that sync() frequently, as the default configuration does. (Of course they're safe, so that makes a sane default.) With that said, the first big thing you're missing is the -q flag to slapadd. Note that if the slapadd -q fails, your only recourse will be a rm. But it looks like your original procedure presumes an rm anyway. Second, if you've got enough RAM to cache your entire database in-memory, you should adjust your DB_CONFIG and/or back-bdb directives to do so. This isn't always possible (depends on entry sizes, number of entries, and other such variables) but if you can do it, the performance is obviously fantastic. You can determine the right size using the methods in the FAQ-O-Matic or, since you're really concerned about load times, one practical method is to run "slapadd -qv" and look if the times between entries slow down -- the disk writes, being orders of magnitude slower, are often visible to the naked eye in my experience. At the end you'll experience a long flush, but that's good -- it should be gunning your I/O capabilities. Well, yes, an atomic mv is going to be quicker than slapadd. IMO the best way to minimize downtime is to have lots of replicas, so you can afford to take as long as you desire with a slapadd in any directory you desire... There are significant performance enhancements in 2.4. Version 2.4.9 seems to be coming along well and hopefully will fix the seg fault issues you experience (if you've can, it'd be a great contribution to grab RE24 from CVS and see if you can reproduce segfaults with those "some searches").