If You're Not Gonna Be Yet-Another-Inference-Provider... Then What?
One thing that puzzles me is how Vercel and Supabase ended up among the fastest-growing companies in developer infrastructure. On Ramp's spend data, which ranks vendors by how fast they're gaining market share, Vercel sits at #3 and Supabase at #5.
In some sense, the problems that Vercel and Supabase are solving are not new. They both entered spaces where the incumbents already had perfectly workable solutions.
When I remember from ye olden days of shipping webapps before Vercel was that we were spoiled for choice. When you google "how to deploy a webapp" you get hundreds of options that seem equally good (Netlify, Heroku, AWS, Render, DigitalOcean, rolling our own box, etc.), and so you sort by price and pick whatever is talked about most on the developer forums and feels good.
And for Supabase, well! Databases are about as commoditized as software gets. Postgres, MySQL, MongoDB, DynamoDB, Firebase, oh, and not to mention SQLite, Redis, CockroachDB, how would we ever choose? Again we sort by price and skim the forums and pick what feels good.
As a founder, entering either category of web hosting and databases can feel almost quixotic. How do you not shake the feeling that you're pouring one more bucket into the ocean?
When I see a market with hundreds of options, usually my first instinct is to think the problem is already "solved."
But upon looking at Vercel and Supabase, I wonder whether it could also mean that it's a category where we haven't yet figured out how to make the obvious choice obvious. Maybe the lack of winner is because all the solutions are just meh-alright.
Once upon a time there was Postgres, then there was Supabase (short)
So the really really short story I want to tell is this:
Once upon a time, there was a commodity (
POSTGRES), and there were zillions of companies trying to sell this commodity ("we'll run POSTGRES for you so you don't have to!"), and then a scrappy little startup (SUPABASE) came along and they had this genius idea of not being yet-another-commodity-seller.
(Vercel's story opens the same way, by the way, the specifics are just a little different.)
If you now want to watch me extrapolate wildly to inference providers based on this story, feel free to just skip to Once upon a time there were inference providers, then there were ??? (a couple of tea leaves never hurt nobody). But I think the long version is also pretty interesting.
Once upon a time there was Postgres, then there was Supabase (long)
Okay, here goes: once upon a time, the commonfolk needed to store info. A lot of databases, enticed by this problem, sought to be the fairest of them all.
Eventually, Postgres became the fairest of them all. (And yes, before you ackshually me... there are absolutely other databases. For this story, let's crown Postgres and move on.)
How to Sell Postgres: Wrong
You, as the budding entrepreneur, can say, "Postgres is great! But the commonfolk don't want to actually run that pile o' infra themselves."
So you then say, "How about I sell Postgres-as-a-service? I buy the servers, I babysit the database, and the thing I sell customers is not having to think about any of that. Million dollar business right there!!"
The problem with having this brilliant idea is that so does everybody else. You're now standing in a field with a thousand other people all shouting "I'll run Postgres for you!" at the same commonfolk, and one of the few leverages anybody really has over each other is price.
Congrats, you'll now undercut each other into thinner and thinner margins in a race to the bottom!
How to Sell Postgres: Right
So this idea of "we'll run Postgres for you so you don't have to" is... not wrong, but needs a little more imagination. Allow me to present thee a better way.
See, Postgres is good. Postgres is also dumb. It's a database and that's it. It doesn't know how to log your users in (authentication) and it doesn't store the files they upload (storage).
If your app needs those things, and most apps do, you go build or buy them somewhere else and wire them in yourself. For authentication you shop around (Auth0, Clerk, maybe Cognito), for storage you shop around (S3, some bucket somewhere), yada yada.
Now, plenty of developers don't want to do all that shopping and wiring.
This is where Firebase comes in. Firebase says, "What if, when developers bring in a database, they didn't need to do all that shopping and wiring?" and put out an all-in-one that worked out of the box. No more shopping around and gluing those services together!
So the Supabase founders, while using Firebase as customers, loved this all-in-oneness. Firebase was almost perfect except they didn't like its pricing and data model.
So they had this bright idea of building an all-in-one like Firebase... except put it on top of Postgres, and fix the things that they couldn't trust about Firebase. Now they are happy and the developers are happy. The end!
Basically, Supabase found a product people loved but wasn't quite perfect (Firebase), and rebuilt that product on top of an open commodity (Postgres). This is a far less exhausting business to be in, and also far more defensible, than attempting to sell Postgres a little bit better than all the other companies selling Postgres.
Once upon a time there were inference providers, then there were ???
So when we squint at this story...
Once upon a time, there was a commodity (
POSTGRES), and there were zillions of companies trying to sell this commodity ("we'll run POSTGRES for you so you don't have to!"), and then a scrappy little startup (SUPABASE) came along and they had this genius idea of not being yet-another-commodity-seller.
...it's hard not to see some form of the inference providers story. Here, I filled in some of the blanks for us.
Once upon a time, there was a commodity (
OPEN-WEIGHT MODELS on HuggingFace), and there were zillions of companies trying to sell this commodity ("we'll run those OPEN-WEIGHT MODELS for you so you don't have to!")
You have all these inference providers running on the dream of "How about I sell inference-as-a-service? I buy the GPUs and fiddle the vLLMs/sglangs and the thing I sell customers is not having to think about any of that. Million dollar business right there!!"
Now, I say that this inference providers story is worse than the databases version. In databases, at least you can "win" by getting customers to pour their data into you, and once they've poured their data into you, they don't feel like migrating it somewhere else, because migrations are a pain in the butt.
In inference, however, you don't really have any data to hold hostage, or anything really to hold hostage, so it doesn't cost the customer anything to switch.
So the way to "win" in inference is to be a hair faster or a hair cheaper this week, until somebody else is a hair faster or cheaper next week. Good lord, there's a new winner every other day that you walk onto OpenRouter.
That can get exhausting pretty fast, so we need to find a new line of business and fill in the blanks for this half of the story:
...and then a scrappy little startup (
???) came along and they had this genius idea of not being yet-another-commodity-seller. Instead, they produced a delightful platform wrapped around said commodity, and everybody fell in love with it, the end!
So if we study Supabase and Vercel, that direction vaguely has to do with building a delightful layer on top of the commodity that makes the commodity pleasant to use.
(By now, you can probably guess where this is going. The problem with having this brilliant idea is that so does everybody else.)
