> We want one thing, and one thing only: "When this fails, in a way where we can't fix it using documentation, experience or the support forums", we need to be

> We want one thing, and one thing only: "When this fails, in a way where we can't fix it using documentation, experience or the support forums", we need to be able to call someone. Everything you're offering below that is useless to us. I don't doubt your expertise in technology. But there are so few companies that can actually do what you describe that it's not a viable market for vendors. The first problem is that the kind of staff you need when things go really bad are (a) really hard to find and (b) are looking for permanent employment. That's why support vendors want term contracts--it's the only way to make the economics work. The second problem: While you say you just want to call your support vendor when something really bad happens, that's actually the most expensive and least satisfying approach for most users, even very expert ones. Far better to engage before there's a failure, e.g., at design time or during regular health checks. Data base upgrade planning is case in point where early engagement pays off in spades. That includes things as simple as having an expert on-call when the upgrade happens. YMMV. That's at least been my experience from 18 years of supporting open source database software.