CodeWalkers is in beta

Michael 'Monty' Widenius and the MySQL Story

Published Updated

Michael "Monty" Widenius is one of the people you have to mention when you talk about practical open-source databases. He was the original developer behind MySQL and later founded MariaDB after Sun acquired MySQL AB and Oracle acquired Sun.

CodeWalkers interviewed Monty in the early 2000s, and the conversation was later cited in open-source research and books. The original interview is reproduced in full below, unedited.

Why Monty Matters

MySQL became the default database for a huge amount of early web software because it was accessible, fast enough for ordinary sites, and easy to pair with PHP. That PHP/MySQL combination shaped how a generation of web developers learned both tools together. It also explains why the rebuilt programming section links the PHP cluster and the SQL cluster so tightly.

MariaDB is the second half of the story. It exists because database stewardship runs well past the technical work, into project governance, licensing, compatibility, and who gets to make decisions when a widely used open-source system changes hands.

The SQL section gives that history a practical map: MySQL for the database most older PHP apps expect, MariaDB for the fork and compatibility story, and MaxDB for the SAP DB branch of the same era. The MySQL vs MariaDB vs MaxDB comparison ties the three names together without pretending they serve the same job.

The CodeWalkers Angle

The useful lesson for developers is structural. Web stacks are built from layers that outlive the fashion cycle, and frameworks, query builders, and hosting platforms all turn over faster than the data model beneath them. That database model still decides whether the application can answer basic questions without lying to itself.

The Original CodeWalkers Interview

Reproduced from the original CodeWalkers interview, archived by the Internet Archive on 10 April 2007. The questions came from CodeWalkers readers and were sent to Monty in October 2002; the answers are his. The introduction above is new writing by CodeWalkers; the interview answers below are Monty's words, unedited.

Michael "Monty" Widenius is the designer and lead programmer for the MySQL database. His database software programming dates back to 1978 and his work with TCX DataKonsult AB, to 1981. Since 1995, Monty has been the primary force behind MySQL, devoting his time to product strategies, software design, and the development and reviewing of MySQL source code. [taken from mysql.com]

Here is your chance to ask Monty any questions you have about MySQL, the database or the company. The top 10-15 questions will be sent off to him on October 22, 2002.

Notepad's question:

I know that MySQL really isn't made to work specifically with PHP alone, but since they're so popular together do you think there might be some type of collaboration in the future? And if so, can you give us any details? If that question doesn't make any sense, do you like beans?

Yes, we have are very interested in a close collaboration with the PHP people. In fact, we already work closely with them to ensure that the MySQL interface that is included with the latest PHP versions are kept up to date. We are also adding new functionality to MySQL that will help PHP users:

Make it possible to read MySQL connection options (like user and passwords) from MySQL option files from within PHP.

Add prepared statements in MYSQL that will work nicely with PHP.

We are adding stored procedures (with the ANSI SQL 99 syntax) to MySQL. When this is done we will add support for PHP inside MySQL (as an alternative stored procedure language).

I can eat beans, but prefer to not eat them every day...

isolti's question:

Hi Monty, I like your product. It works great. My question is what feature(s), if any, is missing from MySQL that is in the proprietary Oracle? What missing feature (if any) could stop somebody from migrating to MySQL from Oracle?

This depends on lot of how your application is written. My belief is that MySQL's current functionally is good enough to make it possible to move a substantial portion of all new database applications to MySQL without any major difficulties.

The major difficulties come with old legacy applications that use either a lot of Oracle specific features or some of the ANSI SQL features that MySQL is still missing.

The biggest stumbling blocks are sub selects and stored procedures. Some applications (but much fewer) are also very dependent on views and foreign keys.

In the MySQL 4.1 source tree we already have working sub selects and we have three guys working on adding stored procedures to MySQL (for MySQL 5.0). Full foreign keys support is also planned for 5.0. In MySQL 3.23 and 4.0 we have only support for foreign keys for InnoDB tables.

When the above accomplishments are met, it will be even easier to migrate from traditional databases, like Oracle, to MySQL.

If you are depending on clustering (where replication is not good enough) or some of the more exotic capabilities of a database like Oracle, then it will still take some time before you can easily migrate to MySQL. Fortunately this is not true for most applications.

In practice we hear every day of people who are migrating from Oracle and other SQL databases to MySQL with good results and we are working hard on our side to ensure that this trend will continue.

webhappy's question:

Considering your long experience in designing databases, what do you consider the most challenging aspect? What parts were the most fun? In addition, because database software usually involves squeezing the best performance, what aspects of computer science do you feel are the most important in developing a next-generation database suite? And finally, do you think designing a database (of course, not something as full-featured as mySQL) could be a fruitful computer science project? :)

The most challenging aspect is to get the code bug-free for a lot of users that use the database in ways that you could not have even imagine when you wrote the code. Apart from that, to get the SQL optimizer to do right in 'most' cases is a challenging task that one could work on for several lifetimes:)

Most fun is the feedback you get from enthusiastic MySQL users who are successfully using your product in different ways and are impressed with how well it works.

The "science" that I find most important in developing databases is to understand how to get things to work in really small systems and design algorithms that are scalable from these to large systems. Unfortunately this is not something that is well known and only people who have had first hand experience with programming on 16K machines (or less) know this by heart.

Yes, designing a database can be a very fruitful computer science project; What can be equally fruitful is to take one of the open source databases (like MySQL :) and extend it to do things that it could not do before. This way you have not only done something that is good for yourself but also something that other people can enjoy and benefit from.

Jesse's question:

You have an interesting business model. Most companies that give away a product haven't been doing so well. I am interested to know where more of your revenue stream comes from, pay for support or paid (non-GPL) licenses? On the same note, what tips would you have for someone pursuing a similar business model?

For the moment the biggest part of our income comes from license sales of the non-GPL licenses, but support and training also provides good income to MySQL AB.

We have found that the GPL license works extremely well if you have a library that you can get very widely used and that is extremely useful to embed in a lot of commercial applications. A database server (MySQL), a language engine (Zend) or a GUI widget kit (QT) are good examples of this. It's not that good for standalone applications that people don't have a reason to embed in their products.

The tip I have is if you create an application and release it as GPL with the intention of selling commercial licenses for a non-GPL version, you should start giving a lot of free support to everyone that uses it and actively help people use and spread it.

I believe that you should NOT later change your license to a non-open source/free software license or have two different versions of the product --one (with less functions) for GPL users and a more featured version for paying customers. It's always better to be fully open source/free software compatible than try to create a hybrid.

imerilai's question:

Do you have plans for seriously developing a GUI for MySQL administration and SQL development? Something like MyCC, but much more functional? Or is your strategy focused on developing the core server and leaving GUI development for third parties?

Our current strategy is to work full time on MyCC and have this as a framework for all future GUI applications.

The idea with MyCC is that anyone should be able to create dynamically loadable 'plugins' to enhance it the way you want.

For example, if you don't like the way the current ALTER TABLE works in MyCC you should be able to code an alternative (better?) interface for ALTER TABLE and easily replace the default functionality with this.

By having a lot of plugins -- some created by us and others created by third parties -- we hope to have all the functionality in the GUI that you could ever ask for.

dimonemon's question:

My question is development related. Are there any, or will there be some books, tutorials, etc. that explain internal structure of MySQL so that curious people like myself can analyze and study the code and understand how subsystems interrelate and work together. Thanks, Dmitriy

This is something that we would really like to see happening and we have been working on this ourselves (albeit slowly because of time constraints).

In the MySQL source distribution the file Docs/MySQL-internals.texi includes a lot of comments of the MySQL source. Whenever we feel that something within MySQL needs to be documented so that we can understand how it works, we add it to this document.

Over time we hope that the above document will grow to cover all aspects of MySQL, but for the moment the source code is the best way to learn the internals of MySQL.

Grok's question:

As any Slashdot poster would be happy to inform you, the four big features missing from MySQL are Stored Procedures, Views, Triggers and Foreign Keys. I happen to disagree with them and think the most needed new feature is better database documentation. PHPMyAdmin has special tables that allow you to do this, but it needs to be more standardized which means the tables need to ship by default. Specifically, Foreign Key documentation and descriptions of each field in a table. This would allow pretty charts of the DB structure, but more importantly would allow those who work with the table to understand more easily how it works. Those above five features aside, what do you think will/would be the most important change to MySQL?

MySQL 4.1 will allow you to store foreign keys definitions and retrieve them for all table types. (Currently we only support this for InnoDB tables). MySQL 4.1 already supports comments for each field, in addition to table comments that 3.23 supports.

Apart from the above features the most important aspect is to add all the other missing ANSI SQL 99 features without making MySQL slower.

We are working on OLAP functionality in 4.1 (CUBE and ROLLUP) and are also constantly researching new ways to make MySQL even faster for data warehousing uses.

Another important feature is the ability to emulate other database syntax to make it easy to emigrate to/from them to MySQL.

lindset's question:

What do you think MySQL's biggest advantage(s) over other Database servers are? And what do you think is the reason for the success of MySQL on the web (MySQL on the backends of sites)?

Speed, reliability and light footprint are the biggest advantages of MySQL.

From the start MySQL was optimized for web applications and when the web took off around 1998 and people started to look around for a database, MySQL was there ready to be used.

In other words, the main reason was being in the right place at the right time with a reliable product that everyone suddenly needed.

Matt's question:

What was your inspiration behind MySQL? Why did you begin development in the first place?

First, MySQL was developed as a SQL interface on an old database motor that I had been working with (and written) over a period of 15 years.

We needed something that would enable web users to get access to the data and David Axmark (a co-founder of MySQL AB) and I thought that SQL would be the best language for this.

In other words, we developed MySQL because we needed it ourselves. We released it as open source because we believed that we had created something good and thought that someone else could probably have some use for it. We became inspired and continued to work on this because of the very good feedback we got from people that tried MySQL and loved it.

andyl's question:

We are currently moving from Access to MySQL, but the one thing that is sorely missed is the reporting features of Access. I know that I can use ODBC to connect and still use Access, but I would really like to get rid of it completely and find a lower cost (and better!) solution. Are there any plans for MySQL to offer something along these lines, or do you know of anything that can do the job?

Over time, the MySQL control center (MyCC) will include most of the functionality in Access that most users need. We have a long way to go for this but as more and more developers use MyCC and add new plugins to this we hope that we we'll have something for Access users in the not too distant future.

You can find the MySQL control center on the download pages at http://www.mysql.com

mynameismonkey's question:

Monty, I love using MySQL thanks to it's speed and ease of installation, not to mention the price. It's finely-honed integration with Apache and PHP have helped dramatically decrease our development time and generally made the world a better place to live in. Yet I am still sad, for I still have trouble anthropomorphizing the software. Help me out and name the bloody dolphin already. [editor: mynameismonkey must have missed that the dolphin was named - Sakila. Would you care to comment on the long process of finding a name instead?]

We got a lot of good suggestions for the name from our poll on www.mysql.com, but every time we decide on one name and did some extra research on this we found that the name was already used for something else or there was some 'bad' word in one of the major languages that could be confused with it :(

We finally decided on Sakila as this is an uncommon African name that represents the global reach of MySQL and the open nature of the company.

After deciding on the name, we did a final exhausting search to ensure that we would not clash with any trademarks and we registered Sakila as a trademark in some key countries.

Sources and Legacy Context

LWN and evolt.org both pointed their readers to the CodeWalkers interview when it was published in 2002.

For the biographical name trail, the public Michael Widenius profile keeps My, Max, and Maria tied to MySQL, MaxDB, and MariaDB in one place. The database guides still use Oracle, MariaDB, and SAP documentation for current technical details; this profile uses that biography only for the historical context.

Sources

  1. [1]
    Michael Widenius profile
    (en.wikipedia.org)
  2. [2]
  3. [3]