MySQL with

[Evoir]

I find myself in a dilema with FQ. You guys are perfect in most every way...

I prefer to have my clients use the same software, same host whenever possible. I have some smaller clients who would not need a Gold or Platnum account, except for the MYSQL. I would prefer to use vBulletin for their bb needs, but don't want to stress them out with a higher monthly fee. Other hosts do offer MySQL at lower level plans, but I don't want to host elsewhere. Like I said, I like to keep everything simple and the same.

I really don't want to buy another UBB licence for this new client (I have bought three for clients) , as I find it lacks certain customizablity. I always find myself apologizing for the interface to my clients. I don't want to get in there and hack files just to change simple things like font size of the nav bar, or placement of the nav bar or login links.

vB is something my clients can grow with, is fully customizable and I feel proud to offer my clients. But, then I have to bump them up two levels just for the MYSQL. I think about other hosting companies, but then I want to stay here. It often takes me a while to convice a client to go with FQ in the first place, then I have to convince them to spend more per month on MYSQL. :(

Couldn't you offer MYSQL at the lower packages with limited bandwith restrictions? Pretty please?

[Terra]

Please View:
http://www.aota.net/forums/showthread.php?s=&postid=49420#post49420

There has not been any changes in the area of MySQL available on any lessor package than Gold as that would only degrade the quality of our MySQL due to rapid saturation...

--
Terra
--The laws of Supply and Demand are at work here--
FutureQuest

[Evoir]

I was just hoping with all the changes... we could see changes like this as well. :(

[Joe]

Evoir,

Take a look at Ikonboard 3 for your current requirements. It has many customisable features and doesn't require MySQL for lower traffic sites. I don't think it requires MySQL for higher traffic sites, but it has the capability if you don't have the bandwidth.

Joe

[Evoir]

Joe,

Thanks for the suggestion. I may look into it. But this also means that I have to learn about yet another bbs. (Which brings my hourly rate down considerably). I may just have to push them up to a GOLD package, or suffice with a UBB. :\

[DB]

Discus (http://discusware.com) runs well on Basic and Silver accounts (CGI + flat databases, optional MySQL for the back-end on the new 4.0 version). The CGI doesn't lend itself to a lot of hacking, but the interface is easily customizable via templates. It wouldn't solve your need to learn another proggie, but it could save your clients some $$$ over time. My clients have been happy with it.

[Matt]

I have a suggestion that I think would solve many requests such as Evoir's (and make some projects I have in mind possible), while preserving FutureQuest's bottom line:

Packaged stand-alone MySQL accounts (i.e. no FTP, e-mail, web hosting included)

Accounts would be billed based on:
1. bandwidth
2. requests/ month
3. storage

Item #1 would factor in the costs of bandwidth. #2 would factor in the cost of processing power #3 would factor in the cost of storage. Packages would start at some fixed rate to factor in labor involved in setting up/ maintaining the accounts. (Am I missing something)

I don't think Evoir's problem is unique (based on other posts that I have read). In some cases (such as low traffic sites), the cost for a full-blown Gold account cannot be justified. This leaves web site owners (or prospective customers) making one of two choices:
1. Flat-file database
2. Choosing another hosting company that includes MySQL w/ cheaper packages

Both of these are bad for FutureQuest. #1 is bad in that this will affect other site owners on the shared server #2 -- obvious, right? :noddy:

Matt

[jak]

described very well matt,

i would also be interested in something like this option. we seem to be heading more towards php and mysql formats - at least in the scripts i need for clients.

i'll trade terra one version of perl for one mysql database. :P

cheers,
julie
jak graphic solutions, inc.

[PaulKroll]

I don't mean to be elitist, but I'd just as soon not see the prices go down or the MySQL become a cheaper service. I don't pay my $40/month to get hooked up to a server that's swamped: I'm paying for MySQL >AND< speed.

That said, Evoir, what about a different tact? Get one Gold service, run several vBulletins on it. You could get a central domain name for the critter, and each would be "domain.com/thisforum" and "domain.com/thatforum". If someone wants to step up beyond some level of service (number of users, bandwidth, however you break it down), you tell them it's time to move to a full Gold package. That way, you can fit six of the bad boys on one account, and have an angle to "sell up" the Gold account.

Mind, I can see Terra reaching for my throat the moment I blurt out the text "several vBulletins". ~# This would be one of those must-police-closely-or-it's-time-for-a-ToS-warning situations. But if the sites get that popular, it's easy to see that they DO need to step up to their own accounts.

Is it really hard to justify $40 to someone for a month of hosting? For their baby? I mean, they want the site to perform well, right? And they want to have easy tools to avoid spam and manage the files on the site, right? How much time will they spend on the site? If the sites' slow, would users bother to come back to it?

Incidentally, someone feel free to put the apostrophes in the right place on my sentences. :)

One of the reasons I pay for FutureQuest is for them not to take the temptation to lower the price, increase the volume, make more money for a while, then lose all their customers and go out of business two months later because their servers perform just as poorly as the other el-cheapo hosting companies do, and the only selling point left is price. At that point, they lose to the host that's $.50 less a month than they are, and that'd just frankly BITE.

$40 isn't even LUNCH MONEY for a week in downtown Chicago. It's just not that much. And as a reseller... you get it CHEAPER... you ARE a reseller since that other thread, aren't you? Allow me to throw this large, stuffed animal at you if you aren't. :)

[DB]

LOL @ Paul

I have to agree, as much as I would like MySQL on my Silver accounts, for the sake of my clients using Gold accounts I'm glad the SQL is fast and reliable.

I've seen this topic come up many times here in the forum, and the bottomline seems to be that the prices FQ would have to charge "just for MySQL" in its present form is about what the difference between a Silver (Basic?) and a Gold account would cost. If you're going to pay the extra $10 or so anyway, why not just upgrade and get all the other perks of a Gold account? I suspect if they could find a way of offering really cheap MySQL without losing any of the advantages of the current set-up, they would have offered it as a VAS already.

[Matt]

I don't mean to be elitist, but I'd just as soon not see the prices go down or the MySQL become a cheaper service. I don't pay my $40/month to get hooked up to a server that's swamped: I'm paying for MySQL >AND< speed.Which is what I was factoring in. The point is that the MySQL accounts would be revenue generating and that revenue would be reflected by usage. Unless MySQL is not set up in such a way that it scales easily, "swamped" MySQL servers wouldn't happen, because the money to upgrade the MySQL servers would be there when it was time to upgrade.

That said, Evoir, what about a different tact? Get one Gold service, run several vBulletins on it. Running multiple vBulletins on one account... wouldn't this tie up the MySQL server just as much as running one vBulletin on 6 accounts?

One of the reasons I pay for FutureQuest is for them not to take the temptation to lower the priceLowering the price... that would be terrible :rolleyes: Seriously, what I was suggesting would not affect pricing on the other accounts.

the bottomline seems to be that the prices FQ would have to charge "just for MySQL" in its present form is about what the difference between a Silver (Basic?) and a Gold account would cost.A stand-alone MySQL account priced at $9.95/mo would be about the difference between a Silver and Gold account... $14.95/mo would be more in line with what I was thinking. However, keep in mind that a Gold account's IRMs can't communicate with the database. The advantage of an IRM is that you don't have to buy another hosting package just to start up a few new web sites. So, to currently do this, one would have to purchase 2 Gold accounts. With the sort of package I'm suggesting, one would purchase 1 Silver account, 1 MySQL account, 1 IRM, and a ~ MySQL cross-connect. With 2 low-traffic sites, the second would be cheaper. As traffic increases, so too would demands on the MySQL server, and correspondingly, price of the package required to meet the owner's needs.

we seem to be heading more towards php and mysql formats - at least in the scripts i need for clients. So am I. Even basic PHP scripts commonly require MySQL. I understand why, since PHP otherwise can't store or read files or data w/ suitably secure permissions set (when PHP is being run as an Apache module). I have a Silver account with a few IRMs. I'd happily purchase a stand-alone MySQL account for $14.95/mo (paid yearly) if it offered me the ability to run PHP + MySQL scripts on both the primary account and its IRMs.

My impression of what FQ is trying to avoid is a Gold account, maxed out with IRMs, all utilizing MySQL databases at full hilt, with the account owner simply paying the price of a single Gold account. If FQ were to offer stand-alone MySQL accounts, in such a case the owner would have to pay for a more expensive MySQL package. At the other end of the spectrum is an account holder with low traffic IRMs requiring MySQL or with multiple Basic/Silver accounts requiring MySQL. The way things are now, FQ can't accomodate such users.

Matt
- Not demands, just suggestions

[dank]

Paul, I had hoped to host a site with FQ along the lines of your multiple vB's on one account suggestion, but it wasn't allowed for understandable reasons.

Dan

[PaulKroll]

it wasn't allowed for understandable reasons
Well, that's telling then isn't it? They're that big a server killer, that even a set of smaller, less traveled ones are not allowed on a single account? Ouch.
wouldn't this tie up the MySQL server just as much as running one vBulletin on 6 accounts
Actually in the light of day I can see where it'd be worse: they'd all be on the same machine. At least on seperate accounts FutureQuest could set them to be several different mysql servers.

The pricing you suggest seems closer to fair, though I don't see the IRMs being allowed to access the db if running several vBulletins on a single full account isn't allowed. Of course, what seems fair to me or you may seem like a horrible atrocity to the FQ folks, so YMMV. For multiple vBulletins per account, the legendary high capacity server might be a possibility, but not knowing the pricing, I have no idea how that would work out for folks.

[dank]

Well, that's telling then isn't it? They're that big a server killer, that even a set of smaller, less traveled ones are not allowed on a single account?
I should have explained myself a bit better. It wasn't actually vB's I was hoping to put to use, rather hosting of several [likely low traffic] searchable databases for clients, which would be similar to a reseller having their clients' forums under a shared domain. The potential for resource abuse from a single domain was the primary concern, not the number of database slurping installations, per se. Now that I think about it, there's a lot of grey area in my take on the explanation. :)

Dan

[Evoir]

Originally posted by PaulKroll:
... you ARE a reseller since that other thread, aren't you? Allow me to throw this large, stuffed animal at you if you aren't. :)

Well,...

I'm not. It just seems like a bit of a hassle, having to bill clients for their web server space. My biz is just me, plunking away making websites. If I am a reseller, then I have to bill my clients and I simply pay FQ for all the packages, right?

[Jeff]

Right, as a reseller you pay FutureQuest and then bill your clients. I actually find this works well - I also started paying for their domains and including that on a single yearly bill to them. Otherwise, I found myself always asking "did you pay this or that" or them asking me "do I have to pay this or did you?". Easier to just have one yearly bill from their webmaster for hosting+domain+routine maintenance to keep it simple, and never having to wonder who paid what when and to whom...

[Evoir]

so then, do you own thier domain?

[Jeff]

No I wouldn't do that. I would always register domains under their name (with them and/or their company listed as the registrant and admin contacts.) I would simply list myself as the billing and tech contacts.

[Evoir]

Jeff,

I am sorry, I didn't mean to infer that you did that. I was just confused about how it all works. Please forgive. What you said makes sense.

[Deb]

The Reseller's Advantage is certainly the way to go when multiple accounts are in the works. Even if all of the accounts are yours alone the Reseller's Advantage offers quite a discount with Gold Packages being "as low as" $17.50 a month! Uhhh yes, that's cheaper than the Monthly Basic Package as listed on the web site. Many reseller's are only paying 89.70 a year for their Basic packages which equates to just under $7.50/monthly.

If you have not considered the Reseller's Advantage yet..by all means check it out! I have no hesitation in noting that FutureQuest offers some of the HIGHEST reseller discounts found on the net with a discount/point foundation.

http://www.FutureQuest.net/Services/Reseller/ Packaged stand-alone MySQL accounts (i.e. no FTP, e-mail, web hosting included)

Accounts would be billed based on:
1. bandwidth
2. requests/ month
3. storage Matt, quite honestly I do not understand what you are suggesting. What I *think* you are suggesting is for FutureQuest to simply offer MySQL as a VAS (Value Added Service) the same as we currently offer extra FTP accounts etc with a monthly fee for the MySQL VAS. However at a rate of $15/month it just does not seem to make sense.

I have considered many times going ahead and putting MySQL up as VAS in that way just so that when people ask (and we do get asked A LOT) I could tell them yes... but at the same time I can see them responding with "But that's no cheaper then just going Gold!" because in the end just upgrading to Gold does make more sense. As far as resource usage we would treat it just as we do with the packages that do include MySQL. Disk Space, Bandwidth, and Resource usage comes from what the full package offers (which again makes going Gold wiser since it provides more of these things).

The only way for FutureQuest to bring the MySQL service down in price is in fact to do like most other hosts..meaning we place MySQL back on the Community Servers to avoid the maintenance costs of the dedicated MySQL servers..but by doing this I would certainly fear the cost of Uptime Guarantee Credits since I wholeheartedly believe it would lower the QOS (Quality of Service) of web site delivery.

Do you guys want MySQL as a VAS at the rate of $15/monthly? Does that really solve something for you? I keep fearing I'm missing something in that area as every time I look at it, while standing in my "Site Owner" shoes, the Gold just makes more sense. When I look at it in my "FutureQuest working shoes" I only see more administrative costs with people then having the ability to turn MySQL on, then off, then on, then off while they add and remove that monthly fee etc. Noting also that Paul Kroll really hit the nail on the head with a great deal of his post (http://www.aota.net/forums/showthread.php?s=&postid=65799#post65799). In the area of QOS offering MySQL to too many would hurt...

Thoughts?

Deb
- Which is cheaper: 2 for a dollar or 50 cents each?

[Matt]

Deb,

I think that it would be better explained by using IRMs as an example. I have site A, which is my commercial site, and site B, which is an experimental/ short-term site. Without a doubt, purchasing hosting for Site A with FQ makes sense... it's worth the investment. Now, imagine that FutureQuest (or any other hosting company) didn't offer IRMs. Would I purchase a whole new package with FQ for Site B, or do I purchase from El Cheapo Hosting, Inc.?

In reality, FQ does offer IRMs... but these do not include MySQL. So, as long as Site B doesn't need MySQL, I'll use FQ's IRM. If, after a while of Site B being on an IRM, I decide that it is worthwhile to invest in Site B, I'll purchase a complete hosting package for Site B. But IRMs don't include MySQL, regardless of what package Site A is using. So, it's back to the question: Would I purchase a whole new package with FQ for Site B, or do I purchase from El Cheapo Hosting, Inc.?

When I put myself in FQ's shoes, I imagine that IRMs aren't allowed to access the primary package's MySQL accounts due to cost/ resource concerns. The assumption that FQ makes (or so I assume), is that 5 IRMs and a primary account all accessing the MySQL server would consume a vast amount of resources (worth more than the cost of the primary package alone). Because so many PHP scripts require MySQL, MySQL may be as much an indicator of server side language choices as the utilization of server resources (i.e. MySQL requirements don't necessarily mean heavy resource utilization).

FQ's current MySQL policy is perfectly suitable (in my opinion) when MySQL requirements correspond with heavy resource utilization. In this case, you want these sites on different packages. But when a MySQL requirement simply means I'm testing a PHP script on Site B, I'm afraid FQ's current policy cannot meet these needs. It's El Cheapo Hosting Company or writing a script on Site A to provide access to the MySQL server to Site B... which technically is a violation of terms (not to mention not a particularly ideal solution from the site owner's standpoint).

Developing Site B w/ El Cheapo hosting company and moving it to a full package on FQ when the time is right is the best way of doing things currently. But since the FQ servers and El Cheapo's servers are usually set up differently, moving the site over might not be a smooth process (particularly when you take into account the additional MySQL factor).

This is why I was suggesting a stand-alone MySQL package. I could purchase a complete hosting package for Site A, an IRM for Site B, and a (single) MySQL package for both (i.e. a MySQL package that accepts connections from Site A and Site B). Now, it is no longer necessary to use El Cheapo Hosting. If Site B becomes popular, I move it to a full package. No need to change anything. As the site becomes more popular (and MySQL resource utilization increases), so does the price of the MySQL package... which is calculated based on bandwidth, storage, and connections/mo. The MySQL package is NOT a gold or platinum hosting package. It is an entirely new package. This makes sense since MySQL has been moved off the community servers.

So, I am not suggesting a VAS. This is a suggestion for a new package offering. As I mentioned previously, the fundamental assumption on my part, is that the MySQL servers are set up in such a way so that they scale easily based on demand. I think that this would be termed "Database Hosting," although I have only seen Microsoft/ Oracle type database hosting accounts. Whether the MySQL accounts were accessible only from FQ servers would be a decision for FQ to make.

Well, this is simply a suggestion of how to take El Cheapo Hosting out of the picture and makes some extra $$. Perhaps this is not as simple an extension of FQ's current capababilites as I am (naively) thinking. Hope this clears things up a bit.

-Matt

[Deb]

Thanks Matt for attempting to clarify ... I'm slow sometimes ;) which is an experimental/ short-term site ....
.... But when a MySQL requirement simply means I'm testing a PHP script on Site B These sites are actually better served by the El Cheapo Hosting Company as they are what our offers avoid... It's these types of sites that come and go quickly, often leaving an amount due, and usually because of the "ability to test cheap" their tests can prove terminal to a Community Server. Note: I am by no means saying that your examples fall directly into that category but rather that the offer which satisfies your examples proves to attract those that do. "Cheap Hosting" attracts "expensive clients" :( This is why I was suggesting a stand-alone MySQL package. ....
.... So, I am not suggesting a VAS. This is a suggestion for a new package offering. This actually would be a VAS since it has to be connected to a package somehow otherwise the DB's contents could never be seen from the web. We likely would not allow the MySQL "Package" to be accessed from sites not hosted by FutureQuest for the same reason we would not allow CGI functionality to be accessed etc... It's a sure fired way to overload the server by attracting the resource users, while the true "profits" go to another host that is permitted to serve up the static pages leaving all of the processing for FutureQuest to deal with (hence our rates would go up up up..)

Building a whole new system to track the MySQL usage separate from the package would take some time... it is, as with most things in this business, a bit more complicated than it sounds. As far as cost for the servers, that too isn't always as simple as "upgrading the server". Remember, MySQL as a whole only allows so many connections so if the usage is heavy the only alternative is to build more servers which means more administration etc etc... Regardless of bandwidth and disk usage, connections to MySQL are "expensive" due to the limited number available. If we make obtaining those connections "too easy/cheap" we risk being swallowed by the cost of the new servers and administration of them w/o having a way to recover those costs...UNLESS..the fee for access is higher and that of course brings us back to the idea that "Going Gold" is cheaper for the end user :P

One thing we cannot do is allow more than one package access to a single MySQL "Package". Without going into a long drawn out post I'll have to ask you to trust me on this one... It _will_ open a can of worms that we need to avoid at all costs as the quality of services would undoubtedly suffer. So if MySQL DBs were sold as a separate offer, they would be restricted to access from a single domain/account each.

The best I've ever come up with is $15/monthly for MySQL Services and with that the Monthly Basic Package ends up costing the same as the Annual Gold and the Silver ends up costing more... therefore the Gold remains the best deal. If I try to lower the fee the fear is a mass exodus for MySQL services which brings us back to the "Limited Connections" issue and that leads to the "Error: Too many connections" which most of us have seen somewhere along the way and it is most definitely a problem with the many hosts that have oversold their MySQL services.. :(

Charging by "number of connections" is a good option on paper however I'm not sure how the techs feel about building a system that can track and limit that area successfully in a production environment. I'll have to talk them about how that works (I'm not tech..).

Deb
- Use all you want... One at a time please 8}

[Evoir]

But what about by bandwith? Why not have a ridiculously low bandwith on the lower level accounts? Wouldn't that keep folks from abusing the MYSQL priveleges? Like, this one customer wants a fourm, but they will probably lucky to have 300 users... and maybe 3 on at a time. ever. But, vBulletin is such a great software, that as the person administering their forums, I'd like them to spend $170 on that versus however much $ on UBB, (which I will find that I have to make excuses for layout issues).

It would just be swell if there was some way to get MySQL on the lower packages. :(

[Terra]

But what about by bandwith? Why not have a ridiculously low bandwith on the lower level accounts? Wouldn't that keep folks from abusing the MYSQL priveleges?
Won't work for the main reason that Bandwidth and Resource usage do not usually correlate one-to-one...

Overall, I do not mind the bandwidth used for the MySQL servers as our switches have plenty of leg room to burst low latency result sets to the Community Servers... It is all in how you shape your QOS profiles...

I have seen some queries that can grind a MySQL server to it's knees and return a 15 byte (or less) result...

I've also seen queries that take a split second to execute and return 1GB+ of results... This happens a lot with Cartesian joins, and someone could accidentally perform one and blast their quota... Next they will be in our Service Desk explaining their situation, showing us their code, table structure, etc etc etc and asking us for an extension...

The main problem with MySQL is *RISK*, as it only takes one site owner's malformed query to overwhelm a MySQL engine and cause slowness for others... Mostly due to Cartesian Joins or lack of proper indexing (and sometimes - overindexing)... They are a bit more fragile then one may think and require a lot of attention and care...

I am not prepared to allow our MySQL engines to have a low point of entry... They are a mission critical full production offering that is to be taken seriously with tested production client code accessing them... They are not meant to be someones toy or general 'what-if' testing server... MySQL is free to the public so their is no excuse to no having the ability to do this on your own local development system... I have seen many low cost hosts that offer MySQL to everyone, and in the dark dusty corners of sysAdmin gathering waterholes - you will see that their frustration level is extremely high because they are forced by their bosses to give MySQL to everyone without understanding or listening to their sysAdmins feedback... In short, MySQL problems are epidemic for these types of hosts, and their clients are nothing short of hostile to any type of hiccup or degradation with their MySQL server... I feel sorry for those sysAdmins, because it is upper management just trying to meet or beat their cutthroating competition without understanding the technical repercussions... But heh, what do they care - they pay the sysAdmins - so they expect them to do their job and make them work right... If they don't, then that is grounds for dismissal, because obviously their competition has a sysAdmin that can do it *cough*right*cough*....

--
Terra
--Think outside the box, but don't forget to look inside first--
FutureQuest

[Evoir]

Actually, reasons like this make me trust you guys so much. I prefer that you have limits and reasons for those limits than pander to my every whim. When I see you being so reasonable it makes me rest easier that you are protecting the servers for all of us to use them. So, no sweat.

[Light]

I share Matt's concerns, regarding sites that could greatly benefit from SQL capability (and it is beginning to look like most of the best apps require it) -- but which are not yet generating sufficient revenue to justify $60+ per month in hosting fees. [Surely there are a number of FQ customers, many of whom might be embarrassed to mention it on the forums, for whom $60+ per month -- especially if this is multiplied by several developing sites -- would be a considerable expense.]

So what do we do? These are not merely "testing" sites (i.e. we are not just experimenting for sheer entertainment), they are ANY sites that do not yet have a defined "mission" or which are in early developmental stages, or which for any other reason are not going to immediately produce enough revenue to justify this kind of expense.

Non-SQL (i.e. flat file) based message boards are not a great solution, if you read the TOS's of a number of hosts who now ban them outright due to their excessive consumption of system resources. But apparently it is either that, or hosting at "El Cheapo," if we are unable to come up with Gold level or better hosting here for EVERY single domain (since IRM's won't allow SQL connections) for which we want or need SQL access.

FQ customers tend to be fiercely loyal, for good reason. I, like everyone else, would prefer to give FQ all of my hosting business if I could -- not only because FQ is so rock-solid reliable in service and performance, but also because they are good people doing good things and I want to support that.

But, it is understandable that rock-solid performance and reliability come with a price. Terra and the rest of the crew are great about explaining why (from a sysadmin standpoint) certain things can only be done in certain ways, if we are all to continue to receive the outstanding performance that we expect.

I wish there were a better alternative that could serve everyone's needs here, but for now it looks like "El Cheapo Host" is the place for any site that needs SQL and is not yet ready to pull its own weight on FQ Gold hosting. Then, if and when the site grows to a point where "solid gold" hosting can be justified as an expense, one can think in terms of moving it to FutureQuest.

[Deb]

For many of us $5/month is a big deal! By no means does "money come cheap" these days so no embarrassment there at all. There is no ignoring the needs for low cost solutions whatsoever....

With FutureQuest we have simply figured out how expensive overloaded servers and/or downtime can be. We would have to adjust our Uptime Guarantee quite a bit to be able to afford the loss in QOS, it's just not a route I can see FutureQuest taking ~#

As far as needing $60/month for MySQL...not at all. Note it does not require the Platinum but rather the Gold... I'd also like to repeat for the sake of those that may have missed it earlier in the thread... The Reseller's Advantage is certainly the way to go when multiple accounts are in the works. Even if all of the accounts are yours alone the Reseller's Advantage offers quite a discount with Gold Packages being "as low as" $17.50 a month! Uhhh yes, that's cheaper than the Monthly Basic Package as listed on the web site. Many reseller's are only paying 89.70 a year for their Basic packages which equates to just under $7.50/monthly.

If you have not considered the Reseller's Advantage yet..by all means check it out! I have no hesitation in noting that FutureQuest offers some of the HIGHEST reseller discounts found on the net with a discount/point foundation.

http://www.FutureQuest.net/Services/Reseller/ I'm hearing a lot about "multiple accounts" etc and if you have at least one Annual Silver or better, then the rest could be receiving some great discounts to help in the pocket book if you order them with a reseller ID# rather than without one...

Deb
- Of course I clip Coupons!

[Light]

Hi, Deb -- thanks for pointing out my dyslexia in reading the plan prices. I could go back and edit my earlier post to change all instances of $60 to $40 ;) but I'll let my faux pas stand so that your reply makes sense in the thread. Still, for some of us even $40 (especially for multiple domains) would be a stretch that might strain the family budget...

A person in this position is not going to think in terms of paying annually, of course. But thanks for pointing out the reseller options, for Future reference. As always, it's great to have such responsive people at your end of the conversation.

Cheers!

[Matt]

Well, this has certainly been informative. Light illustrates a few points better than I did. One idea that occurred to me is "production" mySQL servers, with the 99.5% guaranteed up-time and "development" mySQL servers, with no up-time guarantee. This might solve a few of the problems mentioned in this post. However, this isn't in line with FQ's overall reliability policy.

I certainly respect (and now have a better idea of) FQ's policy and reasoning. FQ is unique in that this discussion is actually taking place between the company and the clients. :) Although I'm disappointed that MySQL packages aren't simpler to implement, I appreciate the explanation. Thanks! -Matt