[leo_e]

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 cache. Pocketbase proves that for 99% of CRUD apps, the bottleneck isn't the database—it's the network latency and the developer's time spent managing k8s manifests.

[davidron]

The bottleneck of most applications is acquiring enough users to hit a technical bottleneck.

[mdnahas]

I’ve used PocketBase in production. We ran into DB issues because the admin page loaded all orders and that climbed over 5000. I didn’t think that was much for a read-only operation, but when 5 staff were loading it every 30 seconds, it occasionally got very slow: 10 to 30 second load times.

Faster Vultr server didn’t help. The recommendation was to redesign the admin page to do search on the server rather than in the client. But that wasn’t possible at the time.

I enjoyed writing on top of PocketBase and running it. The developer was very helpful - quick, useful responses. My brother did his wedding website with it. It’s great for small projects. For higher performance ones, you will need to test and shift your design.

[martin82]

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.

[9notorp]

I have a personal blog set up on the cheapest digital ocean droplet and i went ahead with sqlite for it, there is not much traffic on it and i think something like sqlite is actually the best choice for such projects. I did some benchmarking with a rust cli tool, the name i don't recall right now, something like apache bench but simpler. I wouldn't have the same performance if i had mysql or postgres running on the same machine.

[jitl]

for a 98% read use case like blog SQLite is ideal

[roncesvalles]

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.

[odie5533]

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.

[zoul]

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.

[danlugo92]

> dedicated DB cluster and Redis cache in AWS

Premature optimization final boss.

[denismenace]

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.

[benjaminoakes]

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.

[fermuch]

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

[cweagans]

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.

[denismenace]

No, not at all actually. But I had a lot of applications where at somepoint we needed to add storage of currency in the database. It became relevant for billing or other features. This without the app itself being financial in nature.

[burky]

This and DATETIME. The workarounds for these are mostly fine if you’re just using SQLite as a key value store, but doing translations in SQL queries for these workarounds sounds atrocious.

[mike_d]

90% of people aren't using "SQL" anyway. They are just doing basic CRUD operations on a data store with SQL syntax, usually abstracted through an ORM. The only reason they want a SQL database in the first place is for ACID.

If you find yourself caring about data types or actually writing a query, you should probably setup an actual database server.

[arendtio]

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.