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.
Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase
61–70 of 135 posts
Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase
#62Earlier 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.
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
#63Earlier 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
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
#64Pocketbase 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.
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
#65Pocketbase 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.
Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase
#66Earlier 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
Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase
#67Earlier 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
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
#68To 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
#69Earlier 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
Re: Poor Man's Back End-as-a-Service (BaaS), Similar to Firebase/Supabase/Pocketbase
#70Do 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.