Drupal & MySQL - an open source history

(The below blog is part of the Drupal Meets MySQL blog series by Michael Benshoof, MySQL Consultant @ Percona and Andrew Kenney, VP Platform Engineering @ Acquia)

Together, Drupal and MySQL run some of the largest websites on the planet. Both are renowned for having thriving developer and user communities. But how did they get this way, and what does the future hold? In this series we'll cover the history of these great open source projects, how they work seamlessly together and how best to leverage them in the cloud.

In the late 90s the LAMP stack rose to great prominence and software development on the web has never been the same. Although the acronym has been used flexibly in recent years, the original heart of the LAMP stack for web developers was MySQL and PHP. PHP's growth disrupted Perl and old-school CGI scripts whereas MySQL fulfilled the need for an easy to use and free (although not originally open source) database server.

Together PHP and MySQL allowed web developers to quickly cobble together powerful and dynamic websites on even the cheapest hosting plans. This led to the creation of a plethora of PHP projects including Drupal.

MySQL was launched in 1995 by Michael “Monty” Widenius and David Axmark as a free and actively developed database meant to replace existing commercial database options. Drupal began its life as a message board project but began to greatly expand its capabilities after Dries Buytaert open sourced version 1.0 in 2001. One of Drupal's strengths was its dynamic and extensible nature and from the very beginning MySQL was the backend database as by the early 2000s MySQL had already firmly established itself.

During these early days of Drupal, MySQL was at version 3 and was very capable even if not quite enterprise grade. Drupal and MySQL shared an open source license in the GPL after MySQL AB (the original owners) had adopted the GPL in 2000. The combination of Drupal and MySQL empowered site creators to create expressive websites without writing new HTML code for every change and their open licenses allowed them to proliferate on the web.

While early versions of Drupal had minimal support for other databases, it wasn’t until version 6 that Drupals new Schema API made alternative database support within reach of most Drupal module developers. Drupal 7 continued the core database improvements by completely rewriting the database layer as part of a massive leap forward in Drupal's architecture. The adoption of PHP 5 for Drupal 7 allowed developers to take advantage of the revamped object oriented capabilities in PHP 5 as PHP itself had matured significantly as a language. One of these new capabilities was the PHP Data Objects extension (PDO) that was available as a PECL extension for PHP 5.0 and available in core PHP 5.1. Drupal 7 was the first Drupal version able to take advantage of PDO and this overhauled database layer allowed Drupal core to take advantage of any database engine supported by PDO.

Drupal and MySQL Release History

The adoption of PDO by Drupal core enabled site builders to utilize alternative relational databases such as PostgreSQL or new challenges such as MongoDB in a reliable fashion for the first time ever. PDO allowed for an elegant API to query a variety of backend databases without having to manually write queries. However, even with alternative database support, MySQL was still the standard in the Drupal world as not all modules would work with other databases--a problem that persists to this day.

While Drupal was gaining in prominence in the mid-2000s, MySQL, already the defacto leader in web databases, was improving its reputation in the enterprise. The performance and reliability of MySQL took a great leap forward as the InnoDB engine was added to the project and as organizations such as Google began to use MySQL at scale and contribute their changes back to core. In 2007 and 2008 Google published a series of patches for MySQL 4 that was later ported to MySQL 5 and adopted by MySQL distributions such as Percona Server as best practices. Applications such as Drupal could now utilize and easily maintain a highly reliable and performant database.

Drupal and MySQL reliability under heavy transactional load improved as Drupal switched to using InnoDB as the default MySQL storage engine in version 7. Eventually MyISAM was replaced as the default MySQL storage engine in MySQL itself when InnoDB became the default with MySQL 5.5. InnoDB, a product of the Oracle corporation, was nonetheless dual licensed and has evolved in recent years with forks such as Percona XtraDB which is utilized in MariaDB and Percona Server.

In recent history, Oracle released MySQL 5.6 with excellent performance and stability improvements while the Drupal community has been hard at work on Drupal 8. Drupal 8 does not include a dramatically overhauled database layer but does include a number of backend enhancements that may tie in with the database layer, including:

  • brand new key value store replacing variable_set calls
  • a new file-based configuration system that defaults to caching in the database as a result of the Configuration Management Initiative
  • an improved Entity API
  • a revamped caching layer
  • a native REST framework through the Web Services and Context Core Initiative (WSCCI)

MySQL and Drupal have proven to be perfect open source companions over the years and the future is very bright for both projects. Next in our series we'll cover the LAMP stack in additional detail and what it takes to operate MySQL and Drupal together for true enterprise grade web sites.

Comments

Posted on by Miklos Szel (not verified).

Good article, thanks!

Just a little sidenote regarding the change from MyISAM to InnoDB as default storage engine: when you install a standard Drupal instance and check the indexes you will see something like this:
http://pastebin.com/LtqcNCyz

I think this is a legacy from the time MyISAM was the default engine as it stores its indexes in a different way while the InnoDB uses clustered indexes based on the primary keys making these extra ones redundant.

Of course it's only my best educated guess though :)

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.