←back to thread

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

(github.com)
200 points dcu | 4 comments | 03 Jul 25 15:35 UTC | HN request time: 0.229s | source
Show context
CharlesW ◴[03 Jul 25 17:03 UTC] No.44457094[source]▶
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.

replies(6): >>44457217 #>>44457440 #>>44457602 #>>44459642 #>>44460110 #>>44460962 #
loeber ◴[03 Jul 25 17:58 UTC] No.44457602[source]▶
In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.
replies(5): >>44457929 #>>44458129 #>>44458193 #>>44460475 #>>44464263 #
ncruces ◴[03 Jul 25 18:32 UTC] No.44457929[source]▶
In 2020 Tailscale used a JSON file.

https://tailscale.com/blog/an-unlikely-database-migration

replies(1): >>44457971 #
CharlesW ◴[03 Jul 25 18:36 UTC] No.44457971[source]▶
If you continue reading, you'll see that they were forced to ditch JSON for a proper key-value database.
replies(1): >>44458561 #
1. ncruces ◴[03 Jul 25 19:47 UTC] No.44458561[source]▶
I know. Now see how far JSON got them.

So why wouldn't you just use a text format to persist a personal website a handful of people might use?

I created one of the SQLite drivers, but why would you bring in a dependency that might not be available in a decade unless you really need it? (SQLite will be there in 2035, but maybe not the current Go drivers)

replies(2): >>44459591 #>>44463448 #
2. deepsun ◴[03 Jul 25 22:12 UTC] No.44459591[source]▶
It's self-restriction, like driving a car not using the rear view mirror. Or using "while" loops always instead of "for" loops.

It's great for an extra challenge. Or for writing good literature.

replies(1): >>44459841 #
3. moritzwarhier ◴[03 Jul 25 23:03 UTC] No.44459841[source]▶
You didn't really answer the dependency argument though.

Until the data for a static website becomes large enough to make JSON parsing a bottleneck, where is the problem?

I know, it's not generally suitable to store data for quick access of arbitrary pieces without parsing the whole file.

But if you use it at build time anyway (that's how I read the argument), it's pretty likely that you never will reach this bottleneck that makes you require any DBMS. Your site is static, you don't need to serve any database requests.

There is also huge overhead in powering static websites by a full-blown DBMS, in the worst case serving predictable requests without caching.

So many websites are powered by MySQL while essentially being static... and there are often unnecessarily complicated layers of caching to allow that.

But I'm not arguing against these layers per se (the end result is the same), it's just that, if your ecosystem is already built on JSON as data storage, it might be completely unneeded to pull in another dependency.

Not the same as restricting syntax within one programming language.

4. jpc0 ◴[04 Jul 25 11:08 UTC] No.44463448[source]▶
> SQLite will be there in 2035, but maybe not the current Go drivers

Go binaries are statically linked, unless you expect the elf/pe format to not exist in 2035 your binary will still run just the same.

And if not well there will be an SQLite driver in 2035 and other than 5 lines of init code I don’t interact with the SQLite drover but rather the SQL abstraction in golang.

And if it’s such an issue then directly target the sqlite C api which will also still be there in 2035.