It seems like PocketBase can get you surprisingly far , but I think the real question is what happens once you have consistent production traffic and more complex SaaS requirements.<div>
</div><div>I’m particularly curious about authentication, backups, scaling, migrations, and how much custom work people eventually have to build around it.</div><div>
</div><div>
</div>

PocketBase can work well for a real SaaS. The key question is whether its architecture will continue to fit as the product grows. For an early stage SaaS, its simplicity is a major advantage you can quickly ship authentication, data, and admin features without building everything from scratch. That speed may matter more than theoretical scalability while you’re finding product-market fit.

A big thing with PocketBase seems to be that the early experience can be very different from the production experience. It’s easy to get an MVP running quickly, but the real test is what happens when you need more complex integrations, background jobs, scaling, backups, monitoring, or stricter operational requirements.

I’ve wondered about this too. PocketBase feels like one of those tools that can take you surprisingly far if your product doesn’t have overly complex requirements. The part I’d be most curious about is what happens after the user base and data start growing, because that’s usually where the “great for an MVP” tools reveal their limits.

Yes, I run a real, revenue-generating SaaS on PocketBase. Even though its creator markets it for “small and medium-sized apps,” I’ve found its single-binary setup is so efficient it can handle millions of requests on surprisingly cheap hardware. That said, once I took it to production, I started hitting architectural trade-offs you just don’t see during the MVP stage.

The real test isn’t the MVP—it’s month 6. PocketBase looks great for moving fast, but I’d love to hear from people who’ve handled real users, scaling, backups, and production surprises. That’s when you find out if it’s truly SaaS-ready.

I’ve seen PocketBase used for smaller SaaS projects, and I think it can work surprisingly well if the requirements are straightforward. The built in auth, database, file storage, and APIs make it possible to move quickly without setting up a huge backend stack.The main thing I’d consider before using it for a serious SaaS is how much complexity you expect later. Multi-tenancy, scaling, background jobs, integrations, backups, and more advanced querying can eventually require additional infrastructure. For an MVP or lean SaaS, though, PocketBase seems like a practical option if you understand its limits and have a plan for growth.

• This reply was modified 1 week ago by  Gilbert.

I’ve used PocketBase for smaller projects and honestly, the simplicity is what makes it so appealing. But I’d also be a little cautious about making it the foundation of a SaaS that I expect to grow a lot. The MVP stage can hide a lot of backend problems that only show up once users, data, and edge cases start piling up. Would love to hear from someone who’s actually gone through that growth with PocketBase.

This is the kind of question where production experience matters more than benchmark numbers. An MVP can look perfectly fine until you have real users, background jobs, backups, migrations, and unexpected traffic. I would be interested in the “month 3–6” experience: what started becoming painful only after the SaaS had real customers, and whether those issues were PocketBase limitations or simply architecture decisions made early on.

I’ve had the same question about PocketBase. It feels really easy to get something working quickly, but I’d be more curious about the boring stuff after months in production backups, scaling, migrations, auth edge cases, and how much custom work starts piling up. Would love to hear from someone who’s actually taken a SaaS past the MVP stage with it.

I’ve actually wondered about this too. PocketBase feels really good when you’re trying to get an MVP off the ground because you can move so fast without dealing with a ton of setup. The part I’d be curious about is what happens once you have real users, more data, and more complicated business logic. That’s usually where the simple and convenient tools start showing their limits.

I think PocketBase can be a good choice when starting a SaaS product, especially if you want to build quickly. The real test comes when more people start using the product and the data grows. Some problems may not show up at first but can become clear later. It seems like a good option as long as you know when you may need to move to something bigger.

PocketBase might work perfectly during the early stage, but production introduces things like more concurrent users, larger datasets, backups, migrations, monitoring, and increasingly complex business logic. The interesting part isn’t really whether PocketBase can run a SaaS, it’s what starts requiring extra engineering around it as the product grows.

Ran PocketBase 18 months for a small B2B SaaS. Reliable for read-heavy use, but SQLite’s single-writer lock got painful under concurrent writes, and realtime got flaky with complex filters. No real scaling story past one box. Didn’t feel like a hard wall, more slow workarounds piling up. I’d still pick it pre-PMF, but Postgres for real scale.

This is the part of PocketBase discussions I find most useful, not “can it handle X requests?” but what starts hurting after the product has real users and real data. Early simplicity can be a huge advantage, but the long-term operational experience is the real test.