(no title)
leo_e | 3 months ago
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|3 months ago
mdnahas|2 months ago
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|3 months ago
9notorp|3 months ago
jitl|3 months ago
roncesvalles|3 months ago
odie5533|3 months ago
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|3 months ago
danlugo92|3 months ago
Premature optimization final boss.
denismenace|3 months ago
benjaminoakes|3 months ago
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.
cweagans|3 months ago
burky|3 months ago
arendtio|3 months ago
The ones who warn about it are often the ones who don't care about architecture and just plug stuff together.