Why We Raised Our SaaS Prices

We run a Postgresql database as a service on top of Google, AWS, and DigitalOcean. We recently raised our prices, and enough people have asked why that I thought I’d just write it up for everyone to read.

The data that went into this decision came from lots of customer dev interviews, observed customer behavior, and spreadsheet number crunching. There are three main factors that drove the decision (more on each below):

• Users are mostly price insensitive — we are selling what is mainly a B2B product. Most of our users are spending the company’s money, not their own. We noticed that they simply don’t care very much if our price is lower than the competitor’s, because it’s not their money. Being cheaper was not garnering us a significant return in terms of signups, but it was forcing us to operate on lower gross margins than our competitors.
• User acquisition costs are high — our competitors are either huge corporations with practically unlimited marketing budgets (IBM, Amazon, Google), or else venture capital funded startups attempting to buy market share by losing money hand over fist on customer acquisition. We are bootstrapped. We can’t possibly participate in their eternal AdWords bidding wars, and we need more money to improve our ability to compete in other marketing channels.
• Good tech support costs a lot of money— while most customers are great, a few blame the database for poor performance caused by their broken application architecture. They burn through lots of expensive support time for a couple of months, then churn. It’s hard to distinguish these tire kickers from excellent long term customers who just need a little extra help with getting started. We have to either charge more in order to pay for all that support, or provide a worse support experience to legitimate users. We chose to charge a little more and double down on providing excellent support, while trying to identify what are ultimately app-level issues beyond our control earlier on.

Nobody cared that we were cheaper

When we started out, we looked at the competiton‘s prices and we figured we could do much better. They were charging absurdly high prices, we thought. The input costs involved are not that high; we could charge a lot less! Surely everyone will flock to our service in droves if we are much cheaper than the competition.

Turns out that nobody much cares about getting a slightly cheaper database. Commercial database users are highly price insensitive. I suppose this is because it’s usually their employer’s money they’re spending, not their own. They care much more about reliability and support than getting a lower price. (Indeed, a price that’s too low signals poor quality to some.)

Our prices were too low, and our margins were low as a result. I reviewed our competitors’ prices and estimated their gross margins: our margins were less than half of theirs. This gave them a differential advantage in terms of spending on their service, and at no gain to us, since nobody much cared about our lower prices.

The solution: raise our margins to be approximately in line with the market. Roll the increased revenue back into the company.

Customer acquisition is irrationally expensive

Most of our competitors are either huge corporations (IBM, Amazon, Google) or VC funded. Both groups can afford to flush money down the toilet on customer acquisition and run at a loss for years on end. They’re losing money every month, every quarter, every year, trying to buy market share, in the hopes that they can outlast the competition and be the only remaining monopolist database as a service provider.

We’re bootstrapped, so we can’t afford to play that game. We can’t afford to lay out many years’ worth of customer revenue for a single acquisition. What we can do is grow slowly, without losing money every month, and outlast them. Nonetheless, more (sustainable) money for the acquisition funnel means more revenue, and we are still competing with them in every single channel.

Sure, most of them will burn out in a few years and die or be acquihired, but the market can stay irrational longer than you can stay solvent. For now, they all think they can lock up the market and become the next Oracle before that happens by acquiring customers at a loss. As a result, they’ve bid up all the relevant marketing channels — advertising and everything else — to absurd and unsustainable prices for the foreseeable future.

Thus, we needed to raise our prices, to differentially increase our ability to compete in marketing.

Since nobody seemed to care much about paying a little more anyway, this was an easy decision. Raising prices makes sense as a way to kick off a virtuous customer acquisition feedback loop.

Providing quality support costs a lot of money

We strive to provide the very best support of any cloud software provider out there. I think our customers would agree that there is nowhere you will find better support than at Database Labs. Support is one of the few things a small company can do better than a large one.

Having run a few largish production applications in the big clouds ourselves, and having been through the inevitable downtime episodes, we were thoroughly unimpressed with the average level of support we got from the big cloud vendors. Emails are forgotten or ignored, critical tickets get an indifferent one or two sentence response days later. You’re bounced to a new support agent every day, someone who has no clue what your problem is. They either get it wrong or you have to start over from zero explaining it to them. Forget ever asking for anything custom or special.

The fact is, even if you’re spending five or six figures a month, you’re still a mere rounding error in Amazon’s quarterly spreadsheet. They just don’t care all that much about you or your business. Making you a happy customer has no material impact on their success, so the cost of providing great support is just not worth it in their analysis. They’re still making dumptrucks full of money providing (much cheaper) mediocre support.

We figured we could do a lot better, and I think we have. We bend over backwards to be the guys who fix everything for you and make everything “just work” with your database. But…

The database is not the only piece of the puzzle

Just using a well-operated database won’t fix a broken app architecture. There is no silver bullet. If your app is poorly written, it doesn’t matter how great the database (or the OS, or anything else) underlying the app are.

The database, like everything else, has a finite capacity to support load, ultimately bounded by the hardware that it’s running on. If your app is generating more than that amount of load — quite common when apps are using the database in a poorly thought out or abusive way — it doesn’t matter how well the database is managed and operated — you’re still going to see bad performance from your app.

A significant minority of customers don’t get this. They have unrealistic expectations. They imagine the “managed” database as a black box that should magically fix all their performance issues instantly — after all, their profiler says most of the time is being spent “in the database”! (It doesn’t help that this is exactly the alluring instant gratification snake oil pitch that NoSQL sales reps are throwing at them all day — but that’s a topic for a different article.)

When the app runs slowly because its poorly structured architecture generates orders of magnitude more load than it needs to, they suspect the database of being poorly operated. It doesn’t occur to them that their app is badly designed (and their own ego provides massively fortified defense mechanisms against any such suggestion.) And of course they don’t want to spend a little more to just go to a larger hardware tier; that would mean admitting they were wrong when they (randomly) picked the tier they started out with.

Instead they ask us for configuration tweak after tweak, thinking that there is surely some magic tuning or setting (which we as experienced database administrators ought to know about) which will instantly deliver great performance for the massive load their app is applying to the database. They sometimes spend many times what it would cost to just upgrade to the next hardware tier on paying their app engineers to sit around pulling their hair out trying to make their app load more efficient. They ask support for re-engineering advice on how to do that, then ignore or reject out of hand everything we suggest they do. They’re thinking there must be some quick fix “go faster” config file setting in Rails that they forgot to set, when the problem is that the whole system architecture is badly structured at a very fundamental level.

When their app is still slow a few months later, they decide that Postgres must just inherently suck, cancel, and go off to use the new shiny. Typically a NoSQL sales rep has been whispering in their ear for some time at that point. Meanwhile, we’ve lost tons of money having a whole team of expensive engineers waiting hand and foot on their database because we thought they would become a happy long term customer once their initial issues were worked out.

Provide less support, or charge more?

If we could identify who was in this group upfront, we could simply tell them immediately that Postgres is not going to work out for them and save everyone some time. But we can’t tell upfront. Many great long-term customers also need a little handholding as they onboard.

We had a few options here.

We could have unbundled support costs and started charging people by the hour for support. That is unattractive as a product feature. Our overriding design goal is simplicity. Other providers have Byzantine pricing models, not us. Everything about the customer’s experience should be easy easy easy. If the customer needs support, we ought to just provide it for them, without confusing or frightening them by telling them that they will need to pay $x an hour just to talk to an engineer when something goes wrong. We’re the guys who fix everything and make everything just work, remember.

We could more aggressively reject support requests where we’re pretty sure that the database is not the root problem. While we are now doing this to some degree, we don’t want to go too far with that tactic. Many good, long term customers just need some extra help getting started. We don’t want to drive those people off.

Or, we could raise prices and use that to subsidize the support costs a little more. We probably wouldn’t have raised prices due to this issue alone, but since it also makes sense on the other axes, that’s what we did.

Getting the balance right

Pricing is tricky. You can do a priori price analysis all day long, but in the end the only way to tell whether people will buy at a given price is to make them an offer at that price and see whether they take you up it.

This won’t be the last time we change our prices. The market is always shifting. Input costs are shifting, customer preferences are shifting, competitors come and go. We’ll run these prices for some time period, then evaluate whether revenue is growing like we want. If not, we find out why, adjust, and repeat.

This is the story of the current iteration.

Have we missed something, some critical factor or insight? Let me know: pjlegato@databaselabs.io.