Meeting Mr. Pythian

Last night I had dinner at San Francisco with Paul Vallee, CEO of Pythian.

Just in case you never heard about Pythian: They are a company specializing in remote DBA services. There are other companies that do remote DBA, but Pythian is special, because other companies don’t contribute to the community nearly as much as Pythian does.
They have a Pythian blog, with useful technical articles. Incidentally that was the second blog I started reading (The first was Tom Kyte’s). Their second contribution to the community is even more unique –  Log Buffer – the weekly compilation of everything that is hot in the DBA blogsphere.

With so much community interaction going on, it was not surprising to find out that Paul Vallee is on top of every industry trend and has some unique ideas on where the industry is heading. Talking to him for few hours gave me more stuff to consider than I usually encounter in a week or maybe two.

Paul is a huge believer in the future of MySQL. I know a lot of Oracle DBAs think that MySQL is barely a database, but according to Paul there is a huge demand for DBAs that can manage MySQL, because many organizations find out that in some cases Oracle is too much of a database. I have some experience with MySQL and I can’t say I like it much. On the other hand, I like the MySQL community a lot – it is small, friendly and very helpful to newbies. I’m not sure this nice community realize how much more mature Oracle is. Not just in terms of features, also in things like scientific thinking and optimization methodologies.  MySQL community needs people like Tom Kyte, Cary Millisap and Jonathan Lewis, to give structure to the community knowledge sharing and discussions and add deeper and more methodical content.

As I wrote in the beginning, Paul is working hard to anticipate the trends of the database industry, and he thinks that DBAs that define themselves by vendor (Oracle DBAs vs. SQL Server DBAs) are a thing of the past. The same way that developers tend to work in multiple languages through their careers, DBA careers are heading the same way. I’m not sure I agree with this view, I have a feeling that there is a fundamental reason that makes it sensible for DBAs to stick mostly with one vendor, but it is certainly something interesting to consider.

It was not surprising to hear that Paul believes in hiring the best DBAs he can find, the surprising thing was that he seems to think that a DBA team is about as strong as the best person in the team. A team with one very experienced and competent DBA will be significantly better than the same team without him. It makes sense to me, but it is well known among developers that a team is as good as its *worst* developer, so you really want your team to be as strong as you can get while pretty much everyone is on the same level. Another thing to think about.

As you can tell, it was a pretty interesting dinner 🙂 I’m still a bit stoked that I got to meet a real live CEO, and one that founded a company that I really admire. This is just too cool.

I didn’t post suggested links in a while.  Lutz Hartmann wrote about an interesting  initiative from Oracle and Netapp. I was excited about it for a full hour, before our storage manager told me that since we are moving away from Netapp in the near future (It is not Netapp’s fault! We love Netapp! It is a political decision), we won’t be testing the new initiative.


9 Comments on “Meeting Mr. Pythian”

  1. Hi Chen,
    nice to find you on my blog!

  2. Rudy says:

    The answer is: it depends.
    I’ve been a mysql DBA too for years. Mysql is really perfect for small and simple tasks, but in today’s fast-growing companies, there always comes a day when they grow faster than what they can get out of their infrastructure. With mysql, as currently implemented, you’ll sooner or later hit that wall.

    If a organization chooses mysql for a enterprise level application, being aware of its heavy limits, it will get what it deserves.

    “You cannot have the cake and eat it too” (Tom Kyte).

  3. Hi Chen,
    HARD initiative is not only Oracle & Netapp but also other storage vendors:
    the other members are EMC, Fujitsu, Hitachi, HP, NEC, Network Appliance, Sun Microsystems

    see here:


  4. Sheeri says:


    I’ve worked for many organizations that have fast-growing databases, using MySQL. MySQL can scale, but like Chen says, it doesn’t have the complexity Oracle does, at least not built in. Complexity is much different; Chen is right that Oracle is way more mature. Many businesses are using MySQL as a “starter” database, and many don’t ever see a need to move off of it. Some do, though.

    Chen, I think that it’s interesting that DBA’s are usually vendor-specific. I think DBA’s need to know which is best — sure, if you’re a C programmer you’ll branch into ASP, .NET, C#, or just stick with C. Perl programmers learned PHP and now Python and Ruby. If I’m a PHP programmer, though, I should know the strengths and weaknesses so I can recommend the best language out there — coding something in PHP that’s best coded in Java leads to many problems.

    I feel similarly about databases. I’m a MySQL DBA (and joining the Pythian family next week, I’m very excited!) but I know many of Oracle and SQL Server’s strengths and weaknesses as well, and I’ve recommended Oracle, SQL Server and MySQL to many folks.

  5. I think that Oracle and MySQL have two completely opposite approaches to performance optimization and scalability.

    Oracle has lots of features and tweaks that you can use to overcome some application design issues and help scaling without *too* much considerations from application side. MySQL optimization is usually purely on application development side — there are some things you can tweak but nothing close to Oracle so MySQL DBA’s suggest to application developers how to fix application so that it performs better. Oracle DBA’s have much more flexibility to overcome the problem from within database (though, they should insist more often on application changes).

    MySQL developers have to take more care developing database applications – take more care about concurrency and data integrity especially for update intensive applications.

    My own MySQL experience is quite limited so I might be wrong but this my impression so far. Actually, MySQL has an edge there as its approach tends to fix problems at or close to root cause — there is simply no other alternative for them!

  6. prodlife says:


    It seems that 10g is only supported by Netapp and NEC.

    10g has been around for years now, 11g was released, I’d say its about time for EMC and HP to support 10g HARD too…

  7. prodlife says:


    I’m trying hard to avoid a vendor war on my blog 🙂

    I totally agree with you that every DBA needs some proficiency with multiple vendors, so they can help customers make good decisions.

    However, databases are much more complicated than programming languages. Each DB has its own language, environment, architecture and tools. So, the same way it is rare for developers to work in both PC, MAC and UNIX, it is very difficult for DBAs to be proficient at more than one DB. There are just too many differences.

  8. prodlife says:


    Indeed this is the one great advantage of MySQL.
    In our environment, since the developers pushed MySQL into our production, they also took complete ownership of the performance tuning, which was done, as you said mostly at the application level.
    Made me feel a bit useless as a DBA, but this approach certainly leads to better stuff all around.

  9. Rudy says:

    I don’t think so. In my experience, the mysql bare standard approach is “readers block readers and writers, writers block readers and writers”.
    Is this OK for you? No. Then you go for the InnoDB engine. You get transactions and relational features. First you lose performance with little/no way to improve it (mysql is fast…), then you lose some features you had with myisam engine.
    Do you want clustering? You lose both.
    Do you want stanbys? Be prepared to rebuild them regularly; no physical standbys, just query-level replicas (!).
    Multi-versioning? What’s this all about?

    Is it still so or version 5 has improved?

    I don’t want to hurt anyone, just showed what I’ve found out over the years.

    Bye 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s