Live data from Hacker News

Pocketbase – open-source realtime back end in 1 file

pocketbase.io

181–190 of 211 posts

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

#181

Earlier quoted context omitted.

Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.

Don't many financial transactions in US dollars get stored as integers anyway? The number of pennies, in other words. Then just convert to dollars with a decimal place when needing to display, etc. I recall this being pretty normal regardless of what database you use.

A lot of times they are converted to BigInt and then stored as strings so different languages don't mess with the real value

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

#183

Earlier quoted context omitted.

There’s a high level comparison here [1] but it doesn’t go into much detail about the architecture decisions. TLDR; litestream is continuous, sqlitersync is run as a command.

Here's the page threecheese meant to link: https://sqlrsync.com/help/alternatives This is the very high level architecture: https://sqlrsync.com/help/architecture Source code to the client which explains the code running on your system and how I use safe(r) sqlite3 APIs to copy a running database: https://github.com/sqlrsync/client

Thank you :) so embarrassing

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

#184
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…

Personally the lack of a decimal type make SQLite a no-go for me. Its too much of a hassle to do financial operations completely on the application side.

Do you only build stuff that performs financial operations? I'm not sure why sqlite being suboptimal for this one very specific use-case means that sqlite as a whole is a no-go for you.

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

#185

Beware of pocketbase! I am running my startup wetarseel.ai. You'll be badly locked into one instance with one sqlite file, plus its queries are not mapping to SQL, try a bulk delete and it will choke your entire system, plus other footguns.

This has not been my experience. I've definitely done bulk deletes and things have been fine. Are you sure the problem is pocketbase and/or sqlite?

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

#186

love it. been using for personal projects. some things that still need to be done before v1 launch: - easy data migration in and out (right now is a pain if its large volume of data from other DB eg firebase or sqlite!) - API/programmatic setup of tables (right now its only via UI making it hard to setup large complex tables with variable permissions) - Multi-instance: easiest is to have another pocketbase in "mirror…

There was somebody who was using one of the various sqlite replication tools to do multi-instance pocketbase. I can't remember if it was LiteFS or dqlite or something else, but I remember it scaling pretty well. The majority of applications aren't going to outgrow single-instance sqlite though.

Also, you can do programmatic setup of tables with migrations: https://pocketbase.io/docs/go-migrations/ (also available in JS). I can't remember if pocketbase will automatically write migrations to disk for you or if there's a flag you need to turn on, but you can generate those migrations on a local instance, commit them to VCS, deploy them somewhere, and either run a command to run the migrations or turn on auto-migrate (which does what you'd expect).

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

#187
post #19

Is this really realtime? From looking at the description it sounds more like subscriptions to events of data changes that are dispatched close to the data operation How would realtime even work for a networked system going over tcp? https://en.wikipedia.org/wiki/Real-time_computing

Different kind of real-time computing. This is referring to data updates being streamed to other subscribed clients automatically (if you choose to implement that).

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

#188

How's this different from... a database? Most modern dbs come with auth and some gui. I guess if you need real-time updates this is cool

This gives you an entire API and GUI on top of a database that you can use to bang together a quick CRUD app. There is even a customizable API rules function that will let you e.g. make sure one users data doesn't show up for some other user. https://pocketbase.io/docs/api-rules-and-filters/

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

#189
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 bottleneck of most applications is acquiring enough users to hit a technical bottleneck.

That is not the case any more. The "users" show up in the shape and form of malicious AI crawling bots that don't honor your robots.txt nor apply any kind of self-throttling.

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

#190
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.

Post reply on HN