Sam Lambert, CEO of PlanetScale: dropping the free tier was a great decision
PlanetScale CEO Sam Lambert on why killing the free tier was one of the best calls the company ever made, why he actively steers customers away from PlanetScale when it's the wrong fit, and why the best people should never care what their boss thinks.
Sam Lambert is the CEO of PlanetScale, the cloud database platform that's just launched Postgres support and, in his words, been complete chaos ever since. We talk about why the company dropped its free tier despite the backlash, why PlanetScale deliberately tells some prospective customers to go elsewhere, and why its blog reads more like an interactive engineering essay than marketing content.
We also get into how Sam thinks about making big, contrarian calls as a CEO that not everyone agrees with, and what he actually looks for when hiring the best people.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Since the Postgres launch, it feels like something's genuinely shifted for PlanetScale from the outside. Is that real, or perception?
It's reality. We're a pretty secretive culture, so people can only feel some of it from the outside, but the Postgres launch was huge — it's been complete chaos since then, two weeks in, trying to keep up with everyone who wants to move onto the platform. AI has affected the database industry in a couple of different ways: it's driving a lot of user growth from people doing one-off projects that aren't real production workloads, but it's also meant some very serious, rapidly growing consumer companies need highly available databases at massive scale, and that's exactly what we offer. Trust in infrastructure compounds and transfers socially — when big companies see other big companies succeeding on your platform, it feels de-risked for them. Someone told me recently that the Postgres launch showed we actually have a brand — people already knew what PlanetScale for Postgres meant before we explained it, and when people email wanting to onboard, they already know what they're getting.
Every database company claims to be reliable at scale. How do you actually convey that, rather than just claim it?
You convey it through customers — only they can really advocate for whether you do what you say, and they'll tell people just as loudly when you don't. Some providers have had public failures that become permanent memes; MongoDB is a very mature, very good database today, and people still take digs at it over a decade-old data loss issue on Twitter every day. That's completely unfair, but it lives with you forever, so you have to take reliability extremely seriously — being slow but reliable always beats being fast and unreliable in this world, because the downside is too large. That's part of why it took us so long to move into the Postgres world: we didn't feel we'd even met our own standard in the Vitess and MySQL world yet, and we didn't want to show up in a new community pretending we could add value before we actually could. When we did launch, we led with a bunch of benchmarks specifically to prove the difference was real.
You launch products with real customers already using them, before any public announcement. Why?
Anyone can write a blog post saying their own product is good — that's easy, and we don't want to overhype or overmarket. It's a much harder way to release software, because you can't ship something that isn't actually ready, but when we launch, it's validated by a customer people have probably heard of already running on it. Several of our customers have told us the most popular post on their own engineering blog is the one they did jointly with us as part of a launch. Everyone likes nerding out and being part of something cool, and it's a genuinely good way to announce software.
You're upfront about the workloads you're not good for — OLAP, certain migrations. Why lead with what you don't do well?
We try to be really honest with people about what we can and can't do, even though there's a few million dollars of revenue we'd probably get if we said yes to everything and the customers ended up less happy. A common example: people come to us with what's really an OLAP workload — we're an OLTP database built for extremely fast queries to hydrate a product experience, a completely different set of trade-offs from OLAP, which is built for huge volumes of data and much slower, heavier queries. We regularly tell people to go talk to Snowflake instead. Same with migrations — I had a large prospective customer with a complicated, self-sharded database cluster ask what I'd do, and I told them honestly that if it's working now and moving to us would be really hard, I'd probably just stick with what they have. They looked at me strangely, but I think it earned more trust, and they became a customer anyway. We're also honest that we don't support hobby projects well — our entry-level cluster is $39, which isn't much if you're building a real business, but feels expensive if you're just experimenting or vibe coding.
Dropping the free tier was a genuinely shocking, controversial call at the time. Why do it, and what did the actual metrics show?
I don't feel good that we had to do it, but it was absolutely one of the best decisions we made. Every company effectively has to report their free tier as marketing spend, and it's a very large spend — at a lot of companies, the data just doesn't back up the idea that it converts. It's very rare that someone free for six months suddenly becomes a rocket ship customer; people who are going to pay you usually start paying within the first week or two, and if someone's still on the free tier after three months, they almost never convert. We saw the same power-law pattern at GitHub with repository usage — a tiny fraction of repos get any real activity, and a massive long tail is essentially abandoned student projects. Since killing our free tier, the emails I get asking for it back are almost always students pitching a class project, and I'm not unsympathetic — people have to learn, and they'll be the builders of the next generation of software — but you just know that project is never turning into a production app. We wanted to build an enduring, stable business, and you don't do that giving away things that cost real money forever. Every unprofitable database company sees its runway shrink every time it gets a new user, which is genuinely scary; every person who joins PlanetScale now extends our life and lets us reinvest with real money, not borrowed hopes and dreams.
If you were advising a company like Trigger.dev, who has a free tier and is wondering whether to keep it, how would you think about it?
It's highly dependent on what your business actually does — there are so many companies that would get no growth at all without a free tier, because it removes the friction of asking someone for a credit card before they've even decided if your product is right for them. It also depends what a free tier actually costs you: pure SaaS products often have excellent margins, so giving something away is really just a monetization choice, but database companies are giving away real, non-cheap AWS resources that have to be spun up and run. If you have a genuine cost advantage over incumbents, a generous free tier can even be a competitive weapon — Google did this with Gmail storage against Yahoo's much stingier limits, and it became part of the marketing itself. Privately, so many founders have told me they wish they could kill their free tier and the only thing stopping them is public perception. We did it, got a mixed reaction, but it led to more net growth for the company overall, because people respected that we were healthy enough as a business to make that call.
Your blog, like the interactive caching post, is unusually good — not SEO content. Where does that come from?
It's a borrowed lesson from early GitHub, where I got an education in the voice of the company — how to write with authenticity and not cheapen how you speak; we'd actually CI-check blog posts for mealy-mouthed, wishy-washy phrases. I ended up at GitHub partly because I read a short, well-written post by our now-CTO Ted about MySQL memory allocation, and it stuck with me how good prose married to good technical work can be unfair to your competition — they're stuck doing constant SEO-driven content that produces nothing enduring, while some of our best-performing posts are old but still get referenced because they're genuinely interesting. We've started taking even more time on posts like the caching one, and I don't measure them by a strong call-to-action into the product — if someone reads it and thinks PlanetScale clearly knows something, that's valuable even if it doesn't show up as an immediate signup. You kind of have to go all in on one lane or the other; very few teams can do both cheap SEO content and genuinely good writing well at the same time.
How do you actually make a big, contrarian call as CEO when not everyone around you agrees with it?
I don't presume I'm right about everything — I try to put things out to the company very transparently and we hire genuinely smart people, so there's no point not listening to their feedback. But there's one thing I do believe: running a company gives you a unique perspective, not necessarily a correct one, but you're the only person having certain conversations, and everything ultimately rolls up to you — finance being unhappy about cost, engineering being unhappy about resourcing, all of it. You're also the person who lives with the consequences longest; if the company fails, the founder or CEO is the last person to turn the lights off. I've seen people cave to someone else's decision to give them a win, watched it go wrong, and build quiet resentment about not doing what they actually believed. If you're the one holding most of the consequences, you have to act on your convictions, take them seriously, and accept that people can leave if they disagree — try to be more right than wrong, be genuinely open when you're wrong, and build a track record that earns trust over time.
What do you think the best people actually care about when deciding whether to join you?
I genuinely believe the best people should never care what their boss thinks — the best people I've worked with have intrinsic motivation that far exceeds anything a boss could ask of them. If the company you're joining is a vehicle for achieving your own intrinsic goals, you've found the right one; if you're waiting on someone else's validation to feel satisfied, you might not be thinking in a way that drives you to be most successful. Practically, when I really want to hire someone, I tell them not to tell me who they're going to talk to, but to go find any PlanetScale employee on LinkedIn or Twitter and ask them honestly what it's like — the good and the bad. It works because I'm proud of everyone I'd send to represent us to a customer. You also have to accept your culture won't be right for everyone — I'd be a bad employee at most companies in the world, and that's fine. If you express your culture and opinions deliberately, people can honestly self-select in or out, and it not working out for someone is okay too.
Links & references
- Sam's X ↗
- Sam's LinkedIn ↗
- PlanetScale ↗
- PlanetScale for Postgres ↗
- The caching blog post ↗
- Ted Nyman's X ↗
- Snowflake ↗
- Vitess ↗
This episode is brought to you by WorkOS.