Founding engineer at healthtech startup on Supabase's ready-at-scale credibility gap

We spoke with a founding engineer who has spent most of their career in health tech startups, bouncing between IC and engineering manager roles.

The conversation covers why professional teams choose self-hosted Aurora over Supabase for control and compliance, what architectural credibility signals Supabase lacks compared to tools like Temporal, and how AI code generation is widening the bifurcation between Supabase as a getting-started tool for non-developers versus a non-option for serious engineering teams.

Key points via Sacra AI:

Can you tell me a bit about your professional background and what kind of work you do?

I'm a software engineer. I've bounced between being an IC and an engineering manager. I'm in a very senior role at my current company—I'm a founding engineer. I've helped start a few different teams there and at past companies. I've been almost always in startups throughout my career, primarily in health tech.

How does Supabase fit into that journey? Is it something you're actively using right now, something you used at a previous job, or a mix of both?

It's not something I'm using right now, but it's something I've considered using in the past for building startups.

Was this a formal evaluation for your current company as a founding engineer, or more of a look at a side project or previous venture?

Mostly both.

Roughly when did Supabase first come onto your radar as a serious contender?

The last three years or so.

How did Supabase actually come into the picture? Was there a formal evaluation of alternatives, or was it more organic?

We don't use it at my company today. In the early days, we didn't really do formal evaluations because we were a very small team, and that kind of process wasn't the best use of our time. We wanted to be thorough and make smart decisions, but not spend days writing up docs, pros and cons lists, and all that. So I considered it seriously but not in any formal, documented way—I looked at the alternatives and went from there.

What were the other options on the table, and what ultimately led you away from Supabase?

The main alternative was just self-hosting our own cloud solution—something like Aurora Postgres. For the database and other components, we were always evaluating self-managed options versus a vendor that does everything for you. In a lot of cases, we didn't want to go with the easy plug-and-play solution because we didn't want to worry about vendor lock-in, and we wanted control over costs and billing. For some other use cases, we did go with a fully managed cloud solution, but for the database, we did it ourselves. The main reasoning was that databases aren't that hard to manage yourself—at least from zero to one. We were already familiar with Postgres, Aurora, and those cloud-native solutions, so there wasn't a feature set that the hosted option really offered us that we couldn't get otherwise. Since there was no feature we needed badly enough to justify paying more for it, and because we cared about maintaining control rather than offloading the management, the self-hosted route made more sense. Also, as a health tech startup, we needed very tight controls. Supabase likely has the compliance certifications, but we really wanted to be true owners of our data without any vendor in the middle.

Did you look at their other bundled services like auth or storage, or were you strictly evaluating them as a managed Postgres provider?

We really only looked at it as a managed Postgres provider. For auth, we had a lot of complicated requirements and were evaluating that separately over time. We didn't want to build on top of one vendor—we wanted to build it homegrown from scratch so we'd have full control. So it was really just for the primary Postgres use case.

Did you ever get as far as prototyping or doing a performance comparison between Supabase and Aurora, or did the decision to stick with AWS happen before you actually touched the Supabase product?

The latter—we never actually spun it up. We made the call before doing any POC.

Supabase often pitches their open source foundation as a way to avoid lock-in. In your evaluation, did that carry weight, or did the platform layer on top still feel like too much of a proprietary black box?

It did carry weight. But whether it's databases or other purchasable products, most vendors do offer a way out because they want to address that lock-in concern. Even so, getting off still sucks regardless. For our healthcare platform, we didn't want to dedicate multiple engineers' hours to figuring out how to migrate off a data platform to a different one. We just wanted a move-fast, total-control environment.

If you had gone with Supabase and then needed to migrate back to raw RDS or Aurora, what did you perceive as the biggest technical sticking point that would have made that migration painful?

It's been a while since I thought about that, but the quick ones would be: we have multiple databases that talk to each other, so coordinating all the replicas needed to migrate without any downtime would have been really hard. The more complexity there is, the harder it is to migrate without serious downtime. We also felt that our product and data complexity was going to grow in ways we weren't fully aware of at the start, but we knew they would. We didn't want to take a risk on a vendor we hadn't invested the time to fully understand—specifically, what getting off them would actually look like.

Have you actually used Supabase for any of your own side projects, or did you end up sticking with raw Postgres there as well?

I have for some side projects, but it would have been a while ago.

What was the hook that made you reach for Supabase for side projects, even though you were skeptical of it for professional work?

Just speed—not having to worry about AWS account setup or anything like that. Just being ready to go in a few clicks, something low-risk for a side project. There are no concerns about downtime or getting off it. Ease of use, and getting an idea on paper as quickly as possible. It's good for that.

When you were in that mode, did you find yourself using the bundled features like auth or edge functions, or were you mostly just using it as a quick way to get a Postgres instance?

I didn't really get that far, so it was mostly just Postgres.

Did those projects just naturally fizzle out, or did you ever hit a point where you felt you had to move one of them off Supabase?

They just fizzled out. I lost the time I could dedicate to them and couldn't always spend time on them seriously, so they just died.

Do you think Supabase is making a mistake by bundling so many things like auth, storage, and edge functions, or does that actually make them more attractive to you as a founding engineer looking for speed?

There are two directions here. In the new world of AI and code generation, if you're building a low-complexity application as a solo founder with some engineering ability—or a small team without much deep engineering ability—Supabase as the home for everything could actually be a great path. Non-technical folks can probably navigate Supabase better than a senior dev would even prefer to. For a company-of-one scenario, it's actually a great place because it keeps everything in one easy-to-navigate hub.

The opposite, though, is that the more we can code-generate and build custom tools to our specific needs quickly, the less reason professional engineering teams have to use it. You end up paying for features you could just build yourself, faster than ever. At my company, we build features very quickly because we can spend a day on something that used to take a month. We're moving more and more away from anything non-customizable or non-homegrown because it's much easier to just build what we want, how we want it, without paying a vendor for something that has less of a moat for a serious professional dev team.

Have you actually used tools like Cursor or AI agents to scaffold the kind of backend logic that Supabase usually provides out of the box—like auth middleware or custom database functions?

Definitely—auth and custom database functions we've absolutely done ourselves.

Does that make a platform like Supabase feel more like a toy for beginners, or do you think there's still a performance or security ceiling where you'd eventually want a managed service to take over?

I can't speak to that much, just because I don't know the tool well enough at scale. I know companies use it at scale, so I imagine it does work in a large, professional company environment—I've seen other people do it. But to me, it's more about getting started quickly without a lot of complexity. A good hub for an AI codegen-built application.

If vibe coding tools like Bolt or Lovable started offering their own native integrated database and auth services—basically cutting Supabase out of the loop—do you think Supabase has a strong enough brand or technical moat to stay relevant, or would developers just go with whatever the AI tool suggests?

If you ask me right now, I'd say yes, and people would be thoughtful about what they want to use. But a year from now, if AI code generation continues at the same pace—and all predictions point to AI writing 99 percent of code instead of 80 or 90 percent like today—then Supabase, or any similar tool, will see its brand matter much less. People will just stop caring and assume the AI is making the right call. If the AI decides Supabase is the best choice, it could definitely survive. But from the perspective of developers actively choosing their tools, I wouldn't bet on it.

In your professional context, would you ever trust an AI-suggested native database from a tool like Bolt, or does the fact that Supabase is built on Postgres give it a level of professional legitimacy that a generated backend wouldn't have?

Yes, being built on Postgres does give it some legitimacy.

Did you find Supabase's documentation or dashboard to be a meaningful step up from the AWS console, or is that DX advantage mostly marketing fluff for someone with your level of experience?

AWS docs are famously hard to read and understand—I probably clawed my way through the code more than I actually read every word anyway. Supabase really does make it easy. It's like the ideal get-started experience where you can find what you want very fast. They're doing that well.

Was there ever a specific moment in their docs where you thought this might actually be worth the trade-off even for professional work, or did the compliance and control requirements always act as a hard ceiling that no amount of good DX could break through?

It was the latter. No amount of good DX was going to overcome that, because the DX with Postgres on its own was already very manageable for us. It's not like getting up and running ourselves took four times as long—it wasn't a huge deal. So the fact that Supabase had much better docs wasn't going to be the deciding factor over self-hosted Aurora Postgres.

When you were evaluating it, did features like row-level security or the auto-generated Postgres APIs feel like a productivity boost, or did they feel like a layer of abstraction that would eventually get in the way of a complex health tech backend?

Row-level security was something we might want later, but we weren't sure we needed to commit upfront to a tool that made it easy. And in any case, RLS is something you can do yourself in Postgres without Supabase. It wasn't a feature we needed to pay a vendor to access.

Did tools like Neon or PlanetScale ever enter the conversation as a middle ground between Supabase and raw AWS infrastructure?

No, it was really just Supabase versus doing it ourselves.

What would it actually take for Supabase to win you as a customer for a serious professional project? Is there a specific missing enterprise feature that, if added, would make you reconsider?

I'd have to think about it more, but at this point, no. We're happy with the way we've built our database today, and I can't think of anything off the top of my head that would make us leave.

Zooming out, how would you rate your overall experience with Supabase? What have they gotten really right, and where have they fallen short for a developer with your background?

The same themes I've mentioned—for a developer who wants to start a project in ten minutes, you can do it on Supabase, and that's really awesome. Most engineers really don't enjoy the day-zero work of getting all the basic wires in place for an app. Supabase does a great job there.

Where it might fall short—and I'm not sure if they already address this—it would be nice to have access to your instance with the same level of control you'd have if you were hosting it yourself, while still getting all the nice feature-rich things on day one. But I don't know whether they already do that or not.

If Supabase offered that more transparent, low-level access to the underlying infrastructure, would that have changed your professional evaluation, or was the compliance and vendor risk still the bigger blocker?

Maybe a little—and for a lot of other companies, that could have been a silver bullet. But for our use case, we'd decided it was a hard blocker regardless.

If a fellow founding engineer at a new startup—one that wasn't in health tech—asked for your advice, what would be the specific criteria that would make you say "definitely use Supabase" versus telling them to stick with raw RDS or Aurora?

It depends on the complexity of the application. If they're building a simpler web app, that's a great use case for it. If they're building something like an ads marketplace that needs extreme real-time performance and a much more complex event-based stack, I'd say no. More broadly, I'd ask: is your startup's moat the technology itself, or is it the brand, the social network, the distribution? If the web app is just a delivery vehicle for a non-technical moat, Supabase is probably great. If the software itself is the moat, you're going to need more custom control, because a bundled platform won't give you that uniqueness. If you're building a Glassdoor replica, Supabase is great. If you're building something with a lot more complexity where the software itself is the differentiator, maybe just play it safe and don't go with it from the start.

Have you ever actually seen Supabase fail or hit a ceiling in those high-complexity scenarios, or is that more of an architectural intuition?

It's the latter. I haven't seen it fail in those cases, but from experience solving those kinds of issues, even tools that are purpose-built for event architecture tend to abstract away things you actually want to see when you're trying to debug a production bug. My instinct is that an abstraction-first tool, however well-intentioned, will typically become harder to work with when you need to solve complex production problems.

Do you think Supabase's biggest risk is that they've built a great getting-started tool but haven't yet proven they can be the forever home for high-complexity, high-stakes systems?

Knowing what I know—which isn't a whole lot about their largest customers—yes, that's probably their risk.

Is there anything Supabase could do to signal to a founding engineer in a high-stakes field that they're ready for forever-home status, or is being a managed, bundled platform always going to be at odds with that level of professional control?

A good parallel—though for a different product area—is Temporal for workflows and event-based architecture. Even though it's a managed service, I feel very confident about it at scale. Maybe that's just the marketing I've gotten from Temporal versus Supabase, so maybe both are equally ready or equally not—I don't know. But Temporal really does feel like a ready-at-scale product. Supabase kind of just feels more like...

What is it about Temporal's brand or technical approach that gives you that ready-at-scale confidence you feel is currently missing from Supabase?

A few things. One is that the companies using Temporal at scale are serious companies—a good customer list goes a long way. The second is what I was saying before: when you get to a certain stage as an engineer, you want to be doing things yourself because it gives you more control. Temporal was born out of Uber because they needed to solve a complex distributed systems problem themselves. The fact that it was born out of exactly that kind of high-stakes problem—and that other startups face the same class of issues—makes it feel like a first-principles solution to a real problem. And knowing that the co-founder was the engineer who built distributed systems at Uber gives it a different kind of architectural gravity. Those are the kinds of signals that make it feel serious and validated.

Does Supabase's database branching or CLI for local development help bridge that credibility gap for professional teams?

It's a nice hybrid, but it still wouldn't convince me to use them at serious scale over doing it ourselves. Once you reach a certain scale, you have a dedicated infrastructure team managing these things full-time. It's not like having a managed database means you won't need infra engineers—you'll have other infrastructure to manage anyway. So odds are you'll want to manage the database components yourself too. The "you don't need to worry about it" pitch stops being as compelling when you have people whose entire job is worrying about infrastructure.

Do you think Supabase will eventually hit a growth ceiling where they lose their most successful startups to custom AWS or GCP builds once those companies hire their first dedicated DevOps or infra engineers?

I don't personally know anyone who uses Supabase at that scale and is facing that decision, so it's hard to say. But what I would say is: if the business model is that people adopt it for speed, grow quickly, and then never find time to migrate off—so they stay—I wouldn't bet on that as a long-term model. Building custom from scratch is easier now than it ever has been, and that gap is only widening with AI and cloud tooling.

Does Supabase have the leverage to charge enterprise prices, or does the fact that it's just Postgres underneath create a psychological ceiling on what you'd be willing to pay?

They can, but not to the same extent as something like Snowflake or Datadog—tools where you're paying for performance or capabilities you genuinely couldn't replicate yourself without enormous effort. Those feel like real technical moats. Supabase, to me, feels more like a nice wrapper around things you could do yourself with a bit of time. It's not the kind of tech that you couldn't build if you really tried.

Is Supabase's move into PG Vector and AI-specific features a successful attempt to build a technical moat, or does that also feel like something a senior dev would rather just implement directly in Postgres?

It's a good addition, but it's not a moat. Those features aren't that hard to build yourself. The value is that they're built in already—most apps being developed now have some AI component, so having it ready out of the box is useful. But it's not a deep technical moat you couldn't replicate if you wanted to, as far as I'm aware.

In the developer circles you run in, has the perception of Supabase shifted from being the cool new Firebase alternative to something else, or does it still carry that early-stage hacker energy?

Honestly, I feel like I've been hearing about it less. But that's only anecdotal—maybe I'm just not in the market for tools like this right now, so it's coming across my radar less. Maybe there's just less noise around them than there used to be.

Is there anything else making noise in your circles right now? Has the conversation shifted toward AI-native tools?

Definitely toward AI development tools—things like Codex. Another one that's been interesting is mem0 for AI agent memory: basically a managed service for giving your application a persistent memory layer. That one actually seems compelling because it's a little harder to build out yourself. So yes, the conversation has shifted more toward AI-native tooling and less toward vendor-managed backend services.

Is Supabase's identity as the open source Firebase alternative starting to feel dated—like a 2021 problem that people aren't as worried about anymore?

Yes, but not entirely. Most companies being built now still want a plug-and-play tool, and more are being built without senior engineers who can do everything from scratch. So Supabase isn't going to fade away. But it's going to hit harder in some segments and less in others—exactly the bifurcation I was describing before.

In your professional role, if you had gone with Supabase, what would have been the one "striking out" moment—a specific amount of downtime, a data integrity issue, a support response time—that would make you pull the plug and migrate to Aurora immediately?

Downtime is the easy one. We had another vendor we used for a different product area that was also a bottleneck—it went down for a bit. It was actually nice not to have to diagnose and fix the bug ourselves because we could just wait on them to resolve it. But immediately, the thought was "we have to get off this," because it highlighted just how dependent we were on them, and we don't want to be dependent on anybody.

Did that experience reinforce your general build-it-ourselves philosophy, and how long did it actually take your team to go from "we're getting off" to being fully migrated?

We haven't actually gotten off yet—it's only been the last few weeks. We've made the decision but haven't executed it. The tool isn't that hard to get off, maybe a couple of days of work. The moat just isn't strong enough to keep us there, and we're going to make the move.

If Supabase had been that vendor—the one that went down and sparked that conversation—do you think the migration would have been just as easy, or would the fact that they hold the primary database, auth, and storage have made it a much more painful trap to escape?

Definitely the latter. A lot more work to get off.

This transcript is for information purposes only and does not constitute advice of any type or trade recommendation and should not form the basis of any investment decision. Sacra accepts no liability for the transcript or for any errors, omissions or inaccuracies in respect of it. The views of the experts expressed in the transcript are those of the experts and they are not endorsed by, nor do they represent the opinion of Sacra. Sacra reserves all copyright, intellectual property rights in the transcript. Any modification, copying, displaying, distributing, transmitting, publishing, licensing, creating derivative works from, or selling any transcript is strictly prohibited.