MySQL pricing changes effective 1/1/2007

Since we started, we have never imposed a charge for MySQL processes, choosing instead to fund MySQL out of the general hardware fund provided by the storage charge.

However, as time goes on, MySQL is becoming more of an issue. Not only is each successive release more demanding in terms of CPU and memory, but as time goes by, the things our members are doing with MySQL become more intensive as well.

One good example of this is InnoDB tables. When we started, the current version of MySQL was 3.x and there was no such thing as InnoDB. Even when it became part of the distribution in 4.x, it wasn’t used very often (although its mere presence causes MySQL RAM usage to skyrocket). Now, some applications, like MediaWiki for example, will use InnoDB tables by default. Similarly, we would like to start making MySQL 5 available, but it promises to ratchet up the resource requirements once again.

Originally, we planned to extend the storage-based model to MySQL, but what we’ve found is that not only is this not a great model for MySQL, but the accounting mechanism would waste a lot of disk I/O, which would slow down everyone’s databases. By “not a great model” I mean that our MySQL servers don’t share a storage pool the way our web cluster does; each MySQL server has an independent local RAID to maximize performance. Due to the size of disks these days, these servers always run out of I/O capacity or CPU or memory well before they run out of disk space. MySQL is becoming progressively more expensive to maintain, and we need to find a way to recover the cost of its servers that is based on the resources that actually do run out.

Therefore, we are implementing the following pricing scheme for MySQL, effective January 1st, 2007:

• Your first MySQL process will be charged at a base rate of $0.01 per day.
• Your second (and successive) MySQL processes (if any) will be charged at a base rate of $0.02 per day.*
• If a MySQL process has InnoDB tables enabled, it will be charged an additional $0.01 per day.
• If a MySQL process is in the top 10% of MySQL CPU users for a given day, we will apply a $0.01 surcharge for that day.**

This means that roughly 90% of our members will see a MySQL fee of $0.01 per day (about $3.65 a year over existing prices). In the worst-case scenario, a member’s second MySQL process that has InnoDB enabled and is in the top 10% every single day would top out at $0.04 per day (about $14.60 per year), which is not unreasonable for a MySQL process that’s obviously seeing consistent high-volume usage.

*Once these changes are implemented, we will remove the restriction of one MySQL process per member.

**It is unlikely we will have the mechanism to charge for this in place by 1/1/2007, but if not, it may go into effect at any time after that.

30 Comments

RSS feed for comments on this post.

1. this is good news. mysql performance has become important for websites, and it’s nice to know that you’re going to allocate more resources for that.

   the pricing is, as always, nearly free.

   keep up with the good work.

   Comment by marcantonio — December 2, 2006 #

2. I’m glad to see this happen too. I am a big user of MySQL, and I’d be happy to pay more money for a faster database server.

   Comment by Douglas Muth — December 2, 2006 #

3. I am curious to see how the control panel (which I very much like as it is, btw) will report to me on which days my MySQL processes are in the top 10% of CPU usage.

   Since we’re not talking about an absolute value (“40 bajillion cycles”), but rather relative values (“my anonymous MySQL neighbors got slashdotted, so today I’m not in the top 10 for a change!”), I’d like to see what my usage in absolute terms looks like if possible.

   I mean, this is cheap as hell already, but if I can/need to adjust my PHP apps to stay out of the top 10, I’m skinflinty enough to give it a try.

   Comment by cliff1976 — December 2, 2006 #

4. Provided we are successfully able to implement it, the “top 10%” mechanism will most likely track CPU time per MySQL process, per process ID, per day and there should be some kind of rudimentary report based on that.

   I strongly suspect that the people who find themselves in that rare air on a regular basis will, by and large, fall into two categories: people who will not be too surprised by it, and people who don’t index properly. Fortunately, the latter issue is really pretty easy to fix.

   We’ll probably blog about the subject in more detail, but if you want to jump ahead, the slow query log is pretty handy if you want to find out where your MySQL accesses are slowing down.

   Comment by jdw — December 2, 2006 #

5. Good change. MySQL can be a real beast, so I certainly don’t mind tossing a penny into the pot everyday.

   Comment by Shadin — December 3, 2006 #

6. Sounds like a great idea. I’m happy to pay for MySQL.

   Comment by ttuttle — December 4, 2006 #

7. You are the most amazing guys, going down to counting cents as any engineers would.

   Comment by Chui — December 5, 2006 #

8. Me to more than happy to pay for the great service recieved here.

   Comment by Neale — December 5, 2006 #

9. Arghh – I hate change! lol 😉

   The cost concerned me when I first ready the title. But $3.65pa is hardly going to break the bank.

   As long as proformance is equal or better to current activity, I’m happy!

   😀

   Comment by Ken — December 6, 2006 #

10. Sounds perfectly reasonable. This won’t, of course, affect anyone not using any MySQL processes?

    Correct. -jdw

    Comment by Seamus — December 13, 2006 #

11. Hmm.. I’m using mediawiki as an ad-hoc CMS for my site (because I’m more concerned with getting random content up than a real structure). Will this get me into any trouble you think (site is way low bandwidth)? I didn’t realize mediawiki was quite that intensive on the database side.

    MediaWiki isn’t particularly resource intensive, it just likes InnoDB. -jdw

    Comment by Shawn Fumo — December 13, 2006 #

12. The only thing I would say to counter your logic, which as always seems pretty clear, is that it would be nice to still maintain a free model for experimentation. Maybe a ‘Lowest 10% usage’ bracket. My assumption, which is probably wrong, is that the mere presence of an additional mostly idle MySQL thread adds much memory/IO overhead. How wrong is that assumption?

    I’m not sure it’s what you meant to say, but yes, a completely idle MySQL incurs quite a bit of RAM overhead. -jdw

    Comment by Ben Hanson — December 14, 2006 #

13. Exceptionally reasonable as always.

    So, does stopping an unused MySQL sql process cease the penny/day charge or does something more need to be done?

    Thanks.

    Stopping a MySQL process is not sufficient to avoid the charge. You would need to send us a secure support request and have us remove the process entirely. -jdw

    Comment by DJ — December 19, 2006 #

14. So, basically, there’s no reason to use NearlyFreeSpeech anymore because you’re essentially going to be spending the same amount of money you would if you just went with a fixed-price host?

    I suppose every price increase, no matter how small, is annoying, but I’m not sure what to make of this comment. This is a $0.01/day change for most MySQL users to allow us to provide them with better performance and scalability, not a fundamental change to our pricing scheme. -jdw

    Comment by Anonymous — December 21, 2006 #

15. You guys are awesome. I can never be sure if you guys actually make enough money to keep going, but posts like this really improves confidence. Not only are you fixing a current problem, but also tackling future ones. How reasonable!
    I hope you guys stay in business a looong time.

    PS. You have two suggestions for email only services on your faq. I would like to suggest another: tuffmail.com. They are cheap, yet their custom email configuration tool is extremely flexible and very well engineered. They reminded me of you guys–not there to make a quick buck, but provide real value. I’m not affiliated with them, just a very happy customer. Nearlyfreespeech+tuffmail=bliss.

    Thanks! There may not be any Ferraris (or, ahem, gratuitous Superbowl ads) in our future but we’re having fun and staying in the black, so we’re not going anywhere. We’ll check out Tuffmail… that’s not the first time I’ve heard the name. -jdw

    Comment by retardicans — December 22, 2006 #

16. Not annoying in the grand scheme of things, but a little annoying in the regressive taxation sort of way. I guess I should just increase my traffic so I’m getting a better deal on it and quit bitching, but for an almost-non-existant audience blogger, it’s probably a doubling of my cost. Oh well, still cheaper for me than anywhere else, can’t complain toooo much. 😉

    I don’t know what blog software you’re using, but there are patches floating around for WordPress that make it work with SQLite, and I believe that they’ll be official someday. It’s a great alternative for a low-traffic blog! -jdw

    Comment by abathur — December 24, 2006 #

17. The FAQ entry for MySQL charges says that once MySQL starts getting charged for, normal starges charges will decrease. Is that still the plan?

    As indicated in a related forum post, that is unfortunately not the case. I’ve edited the FAQ entry to reflect this; thanks for catching the error! We are currently exploring ways to lower storage charges for people using enough for the cost of it to matter. -jdw

    Comment by Cliff — December 31, 2006 #

18. This has been implemented.

    As previously suspected, we ran into issues with the CPU measurement, so we have put that on the back burner for awhile.

    We’ve updated our site to reflect the change, but we’re still canvassing it to make sure we didn’t miss anything.

    Comment by jdw — January 1, 2007 #

19. Your comment about patches for WordPress seemed to indicate there was a non-MySQL solution (SQLite) for databases that would not incur the $0.01/day cost.

    Can you clarify this? If I switch to SQLite, am I going to be bitten by something else like a CPU-time limit that prevents it from being persistent? Or a crippling lack of admin interface?

    The extra cost of MySQL doesn’t seem outrageous, and I support realistic pricing for resources I am using, but it does probably triple the cost of my low-traffic personal blog. If there is a free but somehow less functional solution, that would be a good FAQ entry for those looking for something even more NearlyFree.

    SQLite is a lightweight flat file database system (no persistent process) that stores its data right in the filesystem. If the application you are using supports it and your site is low-traffic, it is something to consider. SQLite support is already mentioned in our FAQ. -jdw

    Comment by Joseph Oswald — January 3, 2007 #

20. Also, you should probably update

    https://www.nearlyfreespeech.net/services/hosting.php

    where you give pricing, without MySQL billing, as “the whole deal.”

    I have added MySQL to the list of “optional services … at similarly low prices” after “the whole deal” on that page. Thanks for the suggestion! -jdw

    Comment by Joseph Oswald — January 3, 2007 #

21. The Non-Member FAQ entry ‘How many MySQL databases can I have?’ might also need an update.

    Done, thanks! -jdw

    Comment by Matthijs van der Vleuten — January 4, 2007 #

22. The MySQL part of the entry ‘How exactly are storage charges calculated?’ also needs a bit of attention.

    Got that one too. 🙂 Thanks! -jdw

    Comment by Matthijs van der Vleuten — January 4, 2007 #

23. When reviewing activity on my account, I see the MySQL charges if I look at Daily Detail, but they don’t seem to be included in the Daily Summary totals. Has this not been updated yet for the new charges, or am I just missing something?

    The accounting reports are a little weak currently, but we’re putting together some new code that should improve them all-around in the very near future. -jdw

    Comment by lj — January 9, 2007 #

24. YAY! Thank you NFSN for making additional MySQL databases available.

    Comment by luckyclover — January 14, 2007 #

25. Is there an alternative to MediaWiki that doesn’t incur the same dB premium charges? My site has very little traffic as it is, but I am now paying 3X the amount for it just because of the extra 2 cents a day for the InnoDB issue. It’s still a good deal… but a better deal for someone who’s really getting more traffic. I just use MW for the easy CMS it provides and I’m to lazy lately to maintain a proper web site.

    InnoDB is only $0.01/day. As for alternatives, that is probably a question best suited for our forums, where everyone can respond. -jdw

    Comment by Chris — January 18, 2007 #

26. Hm, I thought there was a MySQL fee and then a InnoDB fee on top of that – thus $0.02/day. I guess I should check the forum… sorry. 🙂

    That’s correct, which is why eliminating InnoDB but leaving MySQL only saves $0.01/day. However, see this forum topic, which shows how to convert MediaWiki away from InnoDB without breaking it. -jdw

    Edit: Turns out that last bit may not be true. See the forum topic for full details!

    Comment by Chris — January 19, 2007 #

27. Will SQLite be affected? ie. do you care about the number of processes for anything other than MySQL?

    Comment by Sean Crago — February 4, 2007 #

28. I’m not sure *why* people are complaining. At the absolute maximum is going to cost $1.24 per month for the most aggregious users, and an average of only 30 cents per month for the other 90% of people using a single MySQL process.

    And if that’s too much, just get rid of your MySQL database. Or, break into your child’s piggy bank.

    Jeesh!

    Comment by Robert Reese — February 6, 2007 #

29. Chris,

    You could always switch to PMWiki instead of MediaWiki. PMWiki is similar, but seems to be a bit easier to use and doesn’t use MySQL, but instead stores everything in a Flat File. It might be worth checking out.

    Comment by Justin — February 11, 2007 #

30. The pricing scheme is fair, but I wish there had been more notification. I had a dormant account that I haven’t checked for months after a project stopped, and I had no clue the billing changed until I logged in today and realized that my balance was somewhat lower than I remembered. For the most part, it seems ok to announce changes on the site (I’m all for email reduction), but it seems reasonable to email your customer base to inform about billing changes, particularly since we don’t get ‘real’ bills.

    RC

    This change was announced a full month in advance, and our site has indicated that a MySQL charge was inevitable for several years prior to that. If you want to receive email notifications of News & Announcements, you can set that up from your Email Notification Preference panel in the member interface. -jdw

    Comment by rclimb514 — February 21, 2007 #

Sorry, the comment form is closed at this time.