Live data from Hacker News

Pocketbase – open-source realtime back end in 1 file

pocketbase.io

191–200 of 211 posts

Re: Pocketbase – open-source realtime back end in 1 file

#191

Postbase uses PostgreSQL and BetterAuth. No GUI yet, but it's in the plan and will be called Admin (Panel). I had the same instinct of using SQLite, but then, after a bit of research, PostgreSQL seemed a better alternative for serious projects.

Looks very cool! Good luck!

Re: Pocketbase – open-source realtime back end in 1 file

#193
post #147

The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom. Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day. We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis…

But you can create a dedicated DB cluster and Redis cache in AWS in 3 clicks. And then you have point in time recovery, replication, automatic failover, and guaranteed uptime. What happens when it's 3 AM and your Pocketbase server crashes? Supabase uses Postgres. I don't see a strong reason to prefer Pocketbase to Supabase for commercial applications. Supabase has a generous free tier and you can scale or self-host.

Yes, you can add an enormous amount of complexity to your app in 3 clicks. Should you? The proverbial night crashes are, in my experience, often much better problem to have than the complexity and cost of AWS.

Re: Pocketbase – open-source realtime back end in 1 file

#194
post #147

The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom. Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day. We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis…

Actually, with a good architecture, SQLite brings you very far. However, you need a solid architecture; otherwise, the journey ends very soon. So people with architectural wisdom can build great things with SQLite.

The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.

Re: Pocketbase – open-source realtime back end in 1 file

#195

I've been trying out Pocketbase on a side project idea. I'm super impressed! Having worked for many years on Django projects, Pocketbase seems like a perfect fit for those small to medium sized projects for which you don't want to create and maintain a traditional backend for. Happy to answer any questions.

is it suitable to maintain internal company KB? small size 15-20 people tech team

Re: Pocketbase – open-source realtime back end in 1 file

#196
post #147

The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom. Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day. We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis…

The problem is HA. People don't go distributed for scale as much as they do to be HA. Scalability is just a nice side-effect of HA.

Re: Pocketbase – open-source realtime back end in 1 file

#197

Earlier quoted context omitted.

https://github.com/pocketbase/pocketbase/blob/master/tools/s... I wouldn't be surprised if that's the performance issue. It seems to be used as in memory cache for all (?) collections and uses a mutex to access them, even on reads. Most (properly set up) databases are pretty good keeping things cached and with a local socket the latency is low. With this setup I'd be very careful to do my own general purpose caching.…

Thanks this is very helpful, can you please look at the code more, specially around inserts and reads why its so slow? I am a lowly frontend developer who got into the SQLite hype due to twitter and DHH from Rails, didn't know how bad SQLite was.

I've just started with go a few weeks ago, so take my info with a grain of salt.

Pocketbase uses a mutex for all the data reads and writes. That means that every write will block any readers for the write duration. If you do a lot of writes this will become quite inefficient quickly. You need some kinds of locking to write data, but if badly implemented it will pretty much roll back all concurrency advantages, you pile up goroutines that just wait to do something.

A good database does go very sophisticated steps to minimize locking, essentially you should expect from a modern database that most reads are lock free. Still it helps to understand how they coordinate locking and concurrency to optimize your applications. I.e. usually you design reads to be ultra fast and do writes in healthy bulk sizes which is also still fast but will net out to have minimum lock time. Slow reads should be done read only replicas or at times there isn't any load. So sqlite isn't slow/bad at all, if you use it correct, like any other decent database.

Below the sqlite WAL mode is explained. It is magnitudes more sophisticated then what pocketbase does. Pocketbase literally negates all that by their own locking strategy. It would likely be more efficient if the just remove their cache layer and fine tune sqlite for their use case.

https://sqlite.org/wal.html

Also if you require a very high amount of writes, that is realtime writes, as opposed to writes that can be delayed, you pretty much enter tough terrain. You need to make very deliberate choices and pay a lot of attention to system design depending on your requirements. So if something falls over from a high amount of writes, it because it's hard.

Re: Pocketbase – open-source realtime back end in 1 file

#198
post #147

The "SQLite doesn't scale" argument is usually just premature optimization masquerading as architectural wisdom. Unless you are actively hitting WAL contention limits (which is surprisingly hard to do on modern NVMe), the operational simplicity of a single binary beats the "scalability" of a distributed mess any day. We’ve normalized a complexity tax where every side project "needs" a dedicated DB cluster and a Redis…

But you can create a dedicated DB cluster and Redis cache in AWS in 3 clicks. And then you have point in time recovery, replication, automatic failover, and guaranteed uptime. What happens when it's 3 AM and your Pocketbase server crashes? Supabase uses Postgres. I don't see a strong reason to prefer Pocketbase to Supabase for commercial applications. Supabase has a generous free tier and you can scale or self-host.

> dedicated DB cluster and Redis cache in AWS

Premature optimization final boss.

Re: Pocketbase – open-source realtime back end in 1 file

#200

I can mirror everyone singing praise to pocketbase here. Once you grasp the concepts (which map pretty closely to SQL concepts, with rules for row-based security), it is by far the easiest way IMO to create a maintainable, robust backend with direct auth integrations and a pleasant interface. I have around 5 instances of pocketbase running on a 10 USD/month Hetzner server, serving thousands of users a day without bre…

What kind of app do you use it for?

A couple of daily word games. https://squareword.org is the biggest one.
Post reply on HN