Sometimes I get questions as to whether Pythian is one of the competitors battling with Oracle for MySQL support. The answer lies in the distinction of product support and operational support.
At Pythian, we are laser focused on supporting applications and data infrastructure using Oracle, MySQL and Microsoft SQL Server products. A vast majority of our Oracle customers (there are few customers who have very old 7.x and 8.x products running without vendor support) have Oracle maintenance subscriptions that include product updates and product support. Product support entitles the customer to open support requests when the product doesn’t perform according to the specifications (bug reports) as well as fill in enhancement requests. It also covers deployment blue-prints and deployment guidelines in the official vendor documentation and support database.
What you can’t expect from product support are answers to questions like these:
- How do I architect my infrastructure?
- How much CPU do I need to run this database
- How do I setup my backups?
- How do I tune that SQL statement?
- What I need to monitor in my environment to keep it healthy and avoid service outages?
Of course you cannot expect product support to login to your systems and help monitor them, recover a corrupted database or resolve performance issues etc.
Oracle customers usually have clear understanding of the differences between product support and operations support and consulting that Pythian provides. Even then, every now and again we hear rare statements like “I’m not renewing our Oracle product support because we now have you, Pythian, supporting our databases.” Hearing that, we’re catching our breath for few seconds and then patiently explain that this is inadvisable and the product support is totally different from what Pythian does.
Because of its open-source nature, MySQL database customers have somewhat less incentive to sign up for product support relying on public community releases and the ability to patch the product themselves but even then there is a clear distinction between product support and operational support.
All that was a long prelude to answering the question — “Is Pythian Competing with Oracle and other vendors for MySQL product support”? The answer is NO — Pythian provides plan, deploy, manage services — we analyze, design, implement and maintain the infrastructure. We are working with the vendor providing product support (or as part of the community at large when it comes to the open-source community MySQL releases).
2 Comments. Leave new
Alex, an Oracle customer who’s considering what they need might usefully look at what they have already purchased at https://mysql.com/support/consultative.html . Resolving performance issues and helping people to work out how to set up their backups are routine parts of the work that we do.
One difference is that we don’t do it in large volumes for each customer. If it’s days of tuning work, that’s really a job for our or other consultants, including Pythian.
Pythian offers excellent and useful services delivered by capable people but it’s good to first use what you’ve already paid for.
For the official view of Oracle, ask a PR person. This is just my opinion.
James Day, MySQL Principal Support Engineer, Oracle UK
Thanks for the link James. What you are linking is actually consulting services. This is normally never included in the base product support fees. In MySQL case, I can assume that Oracle/MySQL needs to provide more justification to convince customers paying for software that can alternatively be used for free altogether.
Based on this services description you referenced, as a potential customer, I would make the conclusion that paying couple thousands per year for MySQL Standard Edition subscription, I will basically have Oracle support take care of many operational and even development tasks since the services reference (quote) “MySQL Support Engineers can connect to your servers remotely and assist you”.
In my practice, such services are never included in product support. Especially, when there is no limited scope because if you do good job on this, the work will automatically flow your way and having flat per-server fees structure doesn’t work well here – it either motivates the vendor to do bad job or makes doing good job cost prohibitive.
Good discussion. Thanks for bringing it up and feedback is always most welcome.