There’s been a lot of confusion (and Fear Uncertainty and Doubt) about The Linux Foundation’s Hyperledger Fabric performance and scale; and, admittedly, a lack of information about best practices that can help you yield improved performance and scale. The reality is that Hyperledger Fabric does perform and scale nicely, given the right compute and networking infrastructure. However, it can also yield results that are inadequate for your application’s needs. As with any newish technology, the impacts on performance range from improper (or should I say unexpected) use, improper fabric application to software, and hardware bottlenecks to be addressed over time. I’m old enough to remember my first experiences with relational databases, which at the time were brand spanking new to the enterprise, much as blockchain technology is today. I recall kicking the tires in some early testing where you could launch a query and go for a cup of coffee before the results were returned (okay, that’s admittedly an exaggeration). The reality is that over the years (decades, actually), the engineering of relational database engines underwent a continuous evolution to improve performance and scale capabilities. Additionally, developers writing applications that leveraged them have had to learn how to best construct schemas, indexes, queries and stored procedures to avoid performance nightmares of their own making. As a result, I’m kicking off this blog series to report on various aspects of Hyperledger Fabric performance and scaling with the intent of helping to set the record straight, provide best practices guidance, and to provide you with the latest information on related improvements to Hyperledger Fabric.