Chatbase goes upmarket on Supabase

Instead of splitting things out as we go, we try to consolidate things more as we do. The technology itself works better when you have things that are closely tied together. That's why we're on Supabase.

Introduction#

Chatbase is the platform behind tens of thousands of customer facing AI support agents in production today. The product started in February 2023 as a way to upload a PDF and get a custom ChatGPT trained on your own data, and it has since grown into a full platform for building agents that not only answer questions but also take action on behalf of customers through services like Stripe, Cal.com, and a long list of other integrations.

Founded by Yasser Elsaid as a bootstrapped, single founder project, Chatbase has grown into an 18 person company with eleven engineers, more than 8,000 paying customers, and an ARR that has climbed past 10 million dollars without a single dollar of venture funding. The next phase is harder than the last one. Chatbase is now moving upmarket into the enterprise, building a more reliable solution for larger customers, and aiming for a 100 million dollar ARR target over the next several years. Through every phase of that journey, from the first weekend of building the MVP to running constant inference workloads against retrieval augmented chatbots that handle millions of customer interactions, the backend underneath the product has stayed the same.

Chatbase runs on Supabase.

This is the story of how a strategy of consolidation onto a single Postgres backed platform let one founder go from zero to 10 million in ARR with a team of 18, and why that same strategy is the spine of Chatbase's plan to get from 10 to 100.

The original challenge: ship a real product before the market moved on#

When Yasser started building Chatbase in late 2022, the GPT3 API had only just become broadly accessible and the ChatGPT moment was about to redefine what users expected from software. He had no team, no funding, and no time to spend stitching together a backend from a database vendor, an auth provider, a storage service, and a real time engine. The competitive window for an AI product in early 2023 was measured in weeks, not quarters.

The challenge was straightforward in its description and brutal in its execution. Yasser needed a backend that could store the source documents customers uploaded, generate and persist embeddings, authenticate users, hold conversation state for every chatbot session, and serve a dashboard that customers would actually use to manage their bots. He needed all of that without hiring a backend engineer, because there was no backend engineer to hire. And he needed it to be ready by the time he was ready to launch.

Supabase is great because it has everything. I don't need a different solution for authentication, a different solution for database, or a different solution for storage.

Going from one to ten is a different game than going from zero to one#

Yasser is clear that the playbook changed once Chatbase had its first cohort of customers. The early phase of any product is mostly a fight for attention, where the question is how to get enough users in the door to learn what works and what does not. The phase Chatbase is in now is fundamentally about reliability and trust.

I think it's very different going from zero to one million than going from one million to ten. After you have this first set of users, things change. It's more about how can I make the product actually useful and have them have full trust in the product, where they're fine being dependent on it even if it's a big part of their business.

Going from 10 million in ARR to 100 million is the same kind of step change again, only larger. The work shifts to building an even more reliable platform that enterprise customers can depend on, brand and trust become a bigger part of the story, and the underlying infrastructure has to keep up without ever becoming the thing the team has to worry about.

The consolidation play: from Pinecone to Postgres, and from many vendors to one#

The instinct of most engineering teams as they scale is to split their stack into specialized tools. Chatbase did the opposite. As the product matured, the team kept pulling functionality back into Supabase rather than spreading it across more vendors.

The clearest example is vector search. When Chatbase launched, Pinecone was the obvious choice for vector embeddings, because that was the standard playbook for a retrieval augmented chatbot in 2023. As pgvector matured inside Postgres, Chatbase migrated the embedding workload off Pinecone and onto Supabase. The win was not just one less vendor on the invoice. It was that everything around the embeddings now lived in the same database.

We did the opposite. We were using Pinecone for vector embeddings because that was the default a few years ago. But instead of splitting out things as we go, we try to consolidate things more as we do.

As Chatbase has grown, the database workload has grown with it, and the team has recently begun a focused effort to optimize the primary instance for the next phase of the company. The trigger is the arrival of meaningful analytical work. Chatbase started using Metabase to drive deeper business reporting in early 2026, which has introduced a daily pattern of heavy analytical queries that pull more data through the database than any typical transactional path ever did.

The concrete payoff shows up in places that are easy to underestimate from a slide deck. Cascading deletes are a good example. If a customer deletes a document or an agent, that delete has to propagate through every related piece of data, including embeddings. With a separate vector vendor, the application has to delete in Supabase, then call the vector service, retry on failure, and reason about what happens if one of those calls succeeds and the other does not. Inside Postgres, a cascade simply happens, with no application code and no failure modes to design around.

The same logic applies to operational support. With one platform, Chatbase has a single point of contact that has full context on every piece of the stack, instead of triaging issues across three or four vendors who each only see their own slice.

It's good to have one point of contact that has a lot of context on the services you're using and how they interact with each other, instead of working with three or four vendors and finding it very hard to pinpoint where something is failing.

Choose the backend your first AI employee already knows#

With Claude Code, Cursor, and Codex now writing a significant share of the code at most AI native companies, the question is no longer just which backend the team likes. It is which backend the LLM already knows cold.

A lot of your interaction with the code is going to be through an LLM. So you want to choose tools that LLMs are very proficient at, that are always updated, and that they know how to use. If Cursor or Claude Code or Codex is your first employee, you wouldn't tell a React dev to do database stuff. Choose the backend where these things are proficient, because they're going to be doing a lot of your work. Right now, that's Supabase.

That framing has practical consequences for Chatbase. When a new engineer joins the company, there is no formal Supabase onboarding. They get a small bug to fix in their first week, and by the second week they are productive inside the data layer. The combination of a Postgres backend that LLMs are deeply trained on and an AI assisted development workflow means new engineers and the company's AI tools converge on productivity almost immediately.

Chatbase runs on Chatbase, and Chatbase runs on Supabase#

The consolidation philosophy is not just about the customer facing product. Chatbase has built a growing collection of internal tools on Supabase that the entire company uses every day, and many of those tools are used by non engineers writing SQL conversationally with AI.

The Go to Market Tracker is one example. When a high value account signs up, an automated workflow enriches the lead with company and contact data and writes it into a Supabase database that the marketing and sales teams can query directly. Anyone on those teams can ask a question like "who signed up in the last two days at a company doing over 10 million in revenue" as a SQL query, and the result populates instantly so the sales team can reach out.

The Employee Generated Content Tracker is another. Chatbase has invested heavily in content from the team, not just from the founder, and the tracker monitors every post against the impression targets the team has set. Both tools were built quickly because spinning up a new Supabase project is trivial, and both are now critical for the way Chatbase goes to market.

Things that used to be blocked by engineering, because only one engineer had access to the database or knew how to write a SQL query, are now unlocked. Our support team has access to the Supabase database. Our marketing team has access. When they need something, they just query.

Engineering for the next phase of growth#

As Chatbase moves upmarket, the database workload has grown with the company, and the engineering team has begun a focused effort to make the primary instance ready for enterprise scale. The trigger is the arrival of meaningful analytical work. Chatbase started using Metabase to drive deeper business reporting in early 2026, and that introduced a daily pattern of heavy analytical queries that pull more data through the database than any typical transactional path ever did.

Working alongside the Supabase team, Chatbase identified that those analytical queries were periodically pushing the primary instance to the limits of its current disk configuration. The database was hitting its 3,000 IOPS ceiling at least once a week and routinely saturating its 125 megabyte per second throughput limit during scheduled report runs. While the average IOPS utilization on the instance is well under half its capacity, the peaks during analytical runs were eating into the file cache and creating IO wait that affected unrelated transactional queries running at the same time.

The plan is straightforward and is exactly the kind of plan that a small engineering team can actually execute. First, identify the worst offending queries from the Postgres logs and from PG Hero, and rewrite or index them where possible. Second, increase IOPS and throughput on the primary instance to take pressure off the disk during peak analytical windows. Third, introduce a read replica that takes over the analytical workload entirely, so that the primary instance is free to handle transactional traffic without contention. Drizzle has native support for routing read queries to a replica, which makes the application side of that move comparatively small.

That work is happening alongside the everyday support relationship, which Yasser describes as one of the more valuable things Chatbase gets out of the platform. The Supabase and Chatbase teams work through a shared Slack channel, walking Grafana dashboards, PG Hero, and the Postgres logs in the same working sessions where the optimization plan got built.

Sometimes we get a message on Slack about higher than normal usage or getting close to a limit on the plan. Having that Slack channel and that open line of communication has been extremely helpful.

Results#

Chatbase has crossed several thresholds on the back of the Supabase stack:

• More than 8,000 paying customers across the platform as of early 2026
• An ARR that has climbed past 10 million dollars on a fully bootstrapped, no funding model
• An engineering team that is 11 out of 18 people, which is unusually engineering heavy for a company at this scale and is only possible because the team does not have to spend its time operating its own backend
• A continuous AI agent workload that runs across the full Supabase stack with database, authentication, storage, real time, and pgvector on a single primary instance, augmented by targeted IOPS and throughput tuning as the analytical workload has grown
• Internal tools across marketing, sales, and support that let non engineers query the database directly, replacing the engineering bottleneck that exists at most companies of Chatbase's size
• A two week MVP that became a multi million visitor product in its first year and is now the foundation underneath thousands of production AI support agents around the world
• Zero major migrations across the entire history of the company

I'm happy with the stack that we started with because we didn't have to do a big migration one or two years in because of an issue with the tech stack.

What's next: going upmarket on the same backend that got Chatbase here#

Chatbase has set its sights on a 100 million dollar ARR target over the next several years, and the company plans to get there with the same engineering led, bootstrapped, customer obsessed approach that took it from zero to 10 million. The work is fundamentally about going upmarket: winning larger enterprise customers, building the kind of reliability those customers expect, and continuing to consolidate the stack rather than fragment it.

The product roadmap includes opening up an AI Co Founder API so that other SaaS products can embed a Chatbase growth agent directly inside their own user experience. On the infrastructure side, the next twelve months of work on Supabase are already mapped. Chatbase will continue to tune the primary instance for transactional performance, introduce a read replica to isolate analytical workloads, and continue working with the Supabase Postgres team on slow query identification and remediation. Longer term, the team is watching the Supabase roadmap for capabilities like Multigres and Iceberg integration, which would give them a path to keep every customer interaction without paying live Postgres prices for cold historical data.

Yasser's advice to other bootstrapped AI founders choosing a backend on day one in 2026 has two parts that compound each other. Choose the thing that lets you move fastest now. And choose the thing the LLMs writing your code already know best. For Chatbase, those two answers were the same answer, and they have stayed the same answer for three years. It's Supabase.

Supabase is going to make you move faster. It's what the LLMs know better than anything else. That's important because a lot of your interaction with the code is going to be through an LLM.