Live data from Hacker News

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

github.com

61–70 of 135 posts

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

#61
post #45

Earlier quoted context omitted.

What’s the other candidate besides pocketbase?

Apologies to anyone who found this unclear — the two near-perfect tiny candidate databases are SQLite and DuckDB.

My understanding is that SQLite is OLTP and duckdb is OLAP. Duckdb is column based so not a great fit for a traditional backend db

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

#62
post #37

Earlier quoted context omitted.

> Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile? Could this allow accessing a local db as well? Would love something that could allow an app to talk directly to a db that lives locally in my devices, and that the db could sync across the devices - that way I still get my data in all of my devices, but it always stays only in my devices Of course this would…

> Btw, does Chrome sync local storage across devices when logged in? No, but extensions have an API to a storage which syncs itself across logged-in devices. So potentially you can have a setup where you create a website and an extension and the extension reads the website's localStorage and copies it to `chrome.storage.sync`. Sounds like an interesting idea actually.

That's a clever solution

I've been playing with chrome extensions recently, and have made them directly talk to a local server with a db. So using extensions, it's relatively easy to to store data locally and potentially sync it across devices

I like the idea of leveraging chrome.storage.sync though, I wonder what the limitations are

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

#63
post #62

Earlier quoted context omitted.

> Btw, does Chrome sync local storage across devices when logged in? No, but extensions have an API to a storage which syncs itself across logged-in devices. So potentially you can have a setup where you create a website and an extension and the extension reads the website's localStorage and copies it to `chrome.storage.sync`. Sounds like an interesting idea actually.

That's a clever solution I've been playing with chrome extensions recently, and have made them directly talk to a local server with a db. So using extensions, it's relatively easy to to store data locally and potentially sync it across devices I like the idea of leveraging chrome.storage.sync though, I wonder what the limitations are

> I wonder what the limitations are

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...

says that there is a 100kb limit, and a 512 KV pair limit per extension.

Quite limiting, but if this pattern becomes popular I don't see why it can't be expanded to have the same limit as localStorage (5MB)

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

#64
post #50

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.

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

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

#65
post #50

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.

Not so sure about this. At scale, sure, but how many apps are out there that perform basic CRUD for a few thousand records max and don't need the various benefits and guarantees a DB provides?

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

#66
post #64
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

Is this a static website? If yes, what do you use to build?

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

#67
post #64
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

Can't argue with what works, but...

All these benefits also apply to SQLite, but SQLite is also typed, indexed, and works with tons of tools and libraries.

It can even be stored as a static file on various serving options mentioned above. Even better, it can be served on a per-page basis, so you can download just the index to the client, who can query for specific chunks of the database, further reducing the bandwidth required to serve.

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

#68
Calling this a Poor Man’s backend isn’t even the wrong name for it. Admittedly, this is what I’d expect from a Sophomore in University.

To the others arguing you should’ve stored the data as a binary, might as well have created an API wrapper around SQLite at that rate and called it “JASW - Just Another Sqlite Wrapper”.

@ OP - what was the inspiration for the project? Were you learning DBs or intending to use this in a production environment for a chat session with GPT or something? Would love to help you improve this, but we’d have to understand the problem we’re trying to solve better.

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

#69
post #64
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

It sounds like you use CSVs to build static websites, not store or update any dynamic data. That's not even remotely comparable.

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

#70
post #14
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…

What about those of us who use multiple devices, or multiple browsers? I've been using local storage for years and it's definitely hampering adoption, especially for multiplayer.

One approach might be to save the file to a shared drive like Google Drive?
Post reply on HN