[throwaway77385]

I see Pocketbase, I upvote. Using it in a few production apps and it's been a very solid experience. Some breaking changes from time to time, but generally very solid. Also has a lot of extensibility built in. Sometimes you might hit a scenario where it doesn't provide what you need, which is when things can get a bit hairy, but nothing a skilled dev can't work around.

[mrbluecoat]

> nothing a skilled dev can't work around.

Agreed. Loved this FAQ notice:

"If you don't have the time to at least skim through the documentation and you plan to solely rely on some AI tool, then please do NOT use PocketBase!"

[Bombthecat]

Yap, not famous enough to train AI on it

[F7F7F7]

It’s getting better on Claude specifically now that training cutoffs are starting to move beyond the end of 2023.

OpenAI models are a little less likely to trip up as long as you keep reminding it that it needs to account for v0.23+

[throwaway77385]

I've found Gemini 2.5 pro to handle it ok. It forgets small things like using the deprecated model instead of baseModel and things like that, but nothing dramatic.

[BrandoElFollito]

This was my exact comment, thanks.

It is a very good piece of work, and extensible with JS (I just tried that). I have a fear about the future because the dev is alone, and responds alone in the discussions. He is also quite, how to say, "rough" in the interactions, which I can completely understand, being the one pulled around by everyone.

This is a very, very good piece of work when you need to decorrelate the back from the front

[throwaway77385]

Ah yes, the joy of maintaining open source software. I have seen many devs burn out over the requests made of them.

I didn't know it was just one maintainer. That can both be a good thing for keeping the product focused, but it is also worrying, as that's a single point of failure. Anything could happen and then the whole project might fall into disrepair.

That factor alone would make me weary of overly relying on Pocketbase. I would hope that if he runs out of time, the project could be handed over to the community, but often the problem is then that we end up with 50 forks, all at different stages of development. I wonder what the best solution to this issue is.

[BrandoElFollito]

I have some open source I maintain, fortunately, it stays very niche so I am not overwhelmed. But I know the pain.

What you are saying about forks is very true. Some very good ideas were started, then semi-abandonned on the way and they ended up with incompatible forks, and finally all of this collapsed.

I have no idea what the correct model could be.

[tajd]

what sort of prod apps are you running from it? keen to learn by what other people are doing

[throwaway77385]

The most substantial one is a local business directory. It's exactly the right level of medium complexity where Pocketbase shines. It's all the standard stuff:

- User signups and auth

- Stripe subscriptions using different subscription levels

- Business listings with image galleries, editable images

- Map with markers for business locations, tags, filterable business categories & tags

I'd say that the way Pocketbase handles collections, you probably don't want data that is too nested (even though there's a JSON type field, which then allows much deeper nesting).

If you're coming from Firebase, you might be used to infinitely nestable collections, but that's not how it works in Pocketbase. So you could either have a ton of collections or use nested data.

But, if for example, you had multiple clients which then need to hold a bunch of nested data, you couldn't have a 'clients' collections which then holds a bunch of collections within it. It's just one level of 'collections' within which each item then has fields.

This works well at medium complexity, but could get complicated if you had, say, a CMS where you'd want a few levels of nesting.