Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

github.com

Post reply on HN
Print view View original

121–130 of 135 posts

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#121

Post by tansan »

r0fl wrote: post #64
loeber wrote: post #50

Earlier quoted context omitted.

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

I use CSV files to run multiple sites with 40,000+ pages each. Close to 1mil pages total Super fast Can’t hack me because those CSV files are stored elsewhere and only pulled on build Free, ultra fast, no latency. Every alternative I’ve tried is slower and eventually costs money. CSV files stored on GitHub/vercel/netlify/cloudflare pages can scale to millions of rows for free if divided properly

The way you write this makes it sound like your websites are pulling from the CSV per request. However, you're building static websites and uploading it to a CDN. I don't think SQL is needed here and CSV makes life way easier, but you can swap your CSV with any other storage device in this strategy and it would work the same.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#122

Post by nickjj »

loeber wrote: post #50
CharlesW wrote: post #29

Pocketbase is already the poor man's BaaS, and is minimalist compared to the two others mentioned. > Data stored in human-readable CSVs The choice to not use a database when two near-perfect tiny candidates exist, and furthermore to choose the notorious CSV format for storing data, is absolutely mystifying. One can use their Wasm builds if platform-specific binaries offend.

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

If you ignore size as a benefit, CSV files still have a lot of value:

    - It's plain text
    - It's super easy to diff
    - It's a natural fit for saving it in a git repo
    - It's searchable using standard tools (grep, etc.)
    - It's easy to backup and restore
    - You don't need to worry about it getting corrupt
    - There are many tools designed to read it to produce X types of outputs
A few months ago I wrote my own CLI driven CSV based income and expense tracker at https://github.com/nickjj/plutus. It helps me do quartly taxes in a few minutes and I can get an indepth look at my finances on demand in 1 command.

My computer built in 2014 can parse 100,000 CSV rows in 560ms which is already 10x more items than I really have. I also spent close to zero effort trying to optimize the script for speed. It's a zero dependency single file Python script using "human idiomatic" code.

Overall I'm very pleased in the decision to use a single CSV file instead of a database.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#123

Post by LikeBeans »

I think that's a neat idea. I often use Google Sheets as a database for my projects. I read 'setup' data and 'log' data. Works well. Most often just append a row at the end for writing. But I can see why a CSV can be a decent idea too especially if it can be edited with a spreadsheet app. So I would put this on a server (a file share) and edit it as needed with Excel/Numbers/Google Sheets etc... and click save. My apps can read it and if writing appends a line then hurray! cool idea.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#124

Post by sneak »

ehutch79 wrote: post #77
bob1029 wrote: post #52

Earlier quoted context omitted.

> isn't fast hashing like SHA-256 bad for it Fast hashing is only a concern if your database becomes compromised and your users are incapable of using unique passwords on different sites. The hashing taking forever is entirely about protecting users from themselves in the case of an offline attack scenario. You are burning your own CPU time on their behalf. In an online attack context, it is trivial to prevent an att…

Users don’t use unique passwords. Don’t expect them to.

For a backend you can enforce unbruteforceable API keys that are long and random.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#125

Post by tehbeard »

gausswho wrote: post #41
TekMol wrote: post #4

Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile? I have started writing web apps that simply store the user data as a file, and I am very pleased with this approach. It works perfectly for Desktop and Android. iOS does not allow for real Chrome everywhere (only in Europe, I think), so I also offer to store the data in the "Origin private file system" which a…

At least on the Android front, I'd prefer the app allow me to write to my own storage target. The reason is because I already use Syncthing-Fork to monitor a parent Sync directory of stuff (Obsidian, OpenTracks, etc.) and send to my backup system. In effect it allows apps to be local first and potentially even without network access, but allow me to have automatic backups. If there were something that formalized this…

The closest I'm aware of is https://remotestorage.io/ , the protocol has been relatively static for a while but not widely adopted.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#126

Post by ehutch79 »

sneak wrote: post #124
ehutch79 wrote: post #77

Earlier quoted context omitted.

Users don’t use unique passwords. Don’t expect them to.

For a backend you can enforce unbruteforceable API keys that are long and random.

What does that look like, and how does that prevent a compromise exposing users whose non-unique passwords are stored in a known broken hash?

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#127

Post by felipeccastro »

throwaway032023 wrote: post #102
MobiusHorizons wrote: post #98

Earlier quoted context omitted.

How exactly do you anticipate using Postgres on client? Or are you ignoring the problem statement and saying it’s better to run a backend?

https://pglite.dev/

Not sure why this was downvoted, but I’d be very interested in learning how well does pglite compares to SQLite (pros and cons of each, maturity, etc)

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#128

Post by gavmor »

TekMol wrote: post #114
gavmor wrote: post #113

Earlier quoted context omitted.

> Hey, you are trying to save your data but the data on disk is newer than when you loaded it You're suggesting an actual API-facilitated data sync via Dropbox? Sure, but at that point why? Unless the data also needs to be read by 3rd party applications, might as well host it myself.

Sure. You brought up Dropbox. Not me.

s/Dropbox/Google Drive/

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#129

Post by sneak »

ehutch79 wrote: post #126
sneak wrote: post #124

Earlier quoted context omitted.

For a backend you can enforce unbruteforceable API keys that are long and random.

What does that look like, and how does that prevent a compromise exposing users whose non-unique passwords are stored in a known broken hash?

if you enforce long random server-assigned api keys they are guaranteed to be unique.

you don’t need bcrypt or pbkdf with api keys, as they are not passwords. they are high entropy and unique and long - unlike passwords.

Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase

#130

Post by MobiusHorizons »

throwaway032023 wrote: post #102
MobiusHorizons wrote: post #98

Earlier quoted context omitted.

How exactly do you anticipate using Postgres on client? Or are you ignoring the problem statement and saying it’s better to run a backend?

https://pglite.dev/

Interesting. TIL
Post reply on HN