Frequently Asked Questions

Q: What is WebScaleSQL?

WebScaleSQL is a collaboration among engineers from several companies that face the same challenges in deploying MySQL at scale, and seek greater performance from a database technology tailored for their needs.

Q: Why is it called WebScaleSQL?

A: While there are a variety of origin stories for the name depending on who you ask, the truth is that the founding contributors to the project are truly passionate about building a version of MySQL that is designed for use at the scale of web companies like Google, Twitter, Facebook, LinkedIn, etc. It is called WebScaleSQL, because that is exactly what it aims to be.

Q: What source code is WebScaleSQL based on?

A: WebScaleSQL is currently based on Oracle's publicly available MySQL 5.6 Community release.

Q: Is this a fork of Oracle's MySQL Community release?

A: No. As long as the MySQL community releases continue, we are committed to remaining a branch – and not a fork – of MySQL that’s focused specifically on the challenges of deploying MySQL at our scale.

Q: What companies and groups are involved?

A: WebScaleSQL represents an opportunity for the scale-oriented members of the MySQL community to work together, and currently Facebook, Google, LinkedIn, and Twitter are involved. We welcome input from anyone who wants to contribute.

Q: Why didn't you base this on MariaDB, Percona Server, Drizzle, etc....

A: We reached a consensus that MySQL-5.6 was the right choice for this, as it has the production-ready features we need to operate at scale, and the features planned for MySQL-5.7 seem like a fitting path forward for us. We will continue to revisit this decision as the ecosystem evolves.

Q: What features are included?

A: WebScaleSQL has already produced exciting results. Working together, the engineers involved in WebScaleSQL have made major changes to aid in development of the new branch including:

  • An automated framework that will, for each proposed change, run and publish the results of MySQL's built-in test system (mtr)
  • A full new suite of stress tests and a prototype automated performance testing system.
  • Several changes to the tests already found in MySQL, and to the structure of some existing code, to avoid problems where otherwise safe code changes had previously caused tests to fail or caused unnecessary conflicts. These changes make it easier to work on the code and helped us get started creating WebScaleSQL.
  • Several changes to improve the performance of WebScaleSQL, including buffer pool flushing improvements, optimizations to certain types of queries, support for NUMA interleave policy, and more.
  • New features that make operating WebScaleSQL at true web scale easier, such as super_read_only, and the ability to specify sub-second client timeouts.

Q: Is building WebScaleSQL just like building MySQL?

We have made a few changes so far, that you may need to know.

  • Building WebScaleSQL requires at least GCC version 4.7, or an equivalent CLang version.
  • To make a WebScaleSQL debug build, use only -DCMAKE_BUILD_TYPE=Debug not -DWITH_DEBUG.
  • WebScaleSQL requires readline-dev or libreadline-dev (depending on the Linux distribution) to build.
  • WebScaleSQL does not currently maintain compatibility for anything except GNU/Linux x86_64.
  • If you make code changes, be aware that we build as C++11 and C99.

Q: How can I report a bug?

A: Check the current issues, and if your issue isn't already known, create a new one, here: https://github.com/webscalesql/webscalesql-5.6/issues

Q: Who can contribute?

A: We’ll be doing everything in the open, so everyone in the MySQL community will be able to take what they want from what we do and contribute however they like. All constructive feedback is welcome, and we are slowly expanding the limited number of groups who can directly propose code changes. Stay tuned for more details on this.

Q: How do you decide which patches are accepted for inclusion in WebScaleSQL?

A: Any patch needs to potentially be useful to more than just the contributor to be considered for acceptance. If the patch is deemed to meet that criteria, the code must be reviewed and accepted by another WebScaleSQL contributor group. For example, when an engineer from Facebook proposes to include a Logical Read Ahead patch, an engineer from Google, LinkedIn, or Twitter must review and accept the code, as well as agree that it has wider usefulness.

Q: Will binaries be provided?

A: No. The focus of WebScaleSQL is to provide a common set of code changes that groups can use as a base to apply further changes that are relevant to their use case. For example, Facebook will base the MySQL binaries they use in house on WebScaleSQL code, however, the build used will include some additional Facebook-specific patches, than may not be valuable or useful to others.