Main-memory database systems achieve high throughput by keeping their data structures entirely in memory, and by taking advantage of parallel execution on multicore hardware. This requires concurrency control (CC), which ensures serializability (or other isolation properties) for concurrently executed transactions. The performance of CC mechanisms has been an active area of systems research. Many differentCC mechanisms claim to improve performance over base-lines such as optimistic concurrency control (OCC). However, main-memory transactions can run so fast that small differences in system design and implementation, often unrelated to CC mechanism, can have magnified impact on performance. For instance, many CC schemes have been motivated by apparent collapse under high contention of the performance of single-version OCC; but when using our own optimistic OCC-based system, we do not observe this collapse. Why is this? And are the observed benefits of new CC designs, such as multi-version and mixed optimistic/pessimistic CC variants, due more to CC mechanisms, or more to implementation differences? In this work, we identify non-CC implementation factors that can have nontrivial impact on transaction performance,and conduct a set of carefully controlled experiments to find their degree of impact. We find that for a high contention OLTP workload, the collapse of other OCC implementations’ performance is caused by non-CC factors such as index contention, index type, and contention regulation. In particular, the index contention we found is present in many systems and has severe adverse performance implications, but is largely overlooked by recent work.