Live data from Hacker News

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

github.com

51–60 of 135 posts

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

#51

My biggest issue with "cheaper" alternatives is the same pathway they all take. Start cheap, gather market, then crank the costs after lock-in. Even "open-source" is abused. First everything is open-source, and then reasons come out for why premium services will be closed source.

>Start cheap, gather market, then crank the costs after lock-in.

"cost"/"price" vocabulary clarification, should you ever want to read or write business plans, communicate with accountants, CFO's, etc.

"costs" are what companies pay for supplies/inputs that the company purchases.

"prices" are what those same companies offer to charge buyers for the products the company sells.

companies want to keep costs down, and companies benefit from high prices. (when you said "crank the costs", it thunks)

since people don't generally operate their lives as companies, it tends to seem like "costs" and "prices" are the same thing, but in addition to the above, "costs" to a company reflect actual expenditures in total, and "prices" represent an advertisement for each of something pending that has not transacted yet.

"cost" is an accounting term, total revenues - total costs = total profits

"price" is a marketing term, $1 each, $10 for a dozen!

(of course this could be quibbled into incomprehensively, which is another thing you should not do in "business communication", always streamline communication to get to the takeaway as quickly as possible)

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

#52

> Another important file is _users.csv which contains user credentials and roles. It has the same format as other resources, but with a special _users collection name. There is no way to add new users via API, they must be created manually by editing this file: admin,1,salt,5V5R4SO4ZIFMXRZUL2EQMT2CJSREI7EMTK7AH2ND3T7BXIDLMNVQ====,"admin" alice,1,salt,PXHQWNPTZCBORTO5ASIJYVVAINQLQKJSOAQ4UXIAKTR55BU4HGRQ====, > Here we…

> 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 attacker from cranking through a billions attempts per second and/or make the hashing operation appear to take a constant amount of time.

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

#53
post #18

Why CSV instead of newline-separated JSON arrays? Ambiguity in your storage format isn’t good in the long run… JSON lines can be trivially parsed anywhere without a second thought.

In hindsight, JSONL would have been much easier to deal with as a developer. But I still don't regret picking CSV -- DB interface is pluggable (so one can use JSONL if needed), and I deliberately wanted to have different formats for data storage (models) and data transfer objects (DTOs) in the API layer, just like with real databases. I agree, CSV is very limited and fragile, but it made data conversion/validation part more explicit.

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

#55
post #8

Earlier quoted context omitted.

Golang does not have built in SQLite. It has a SQL database abstraction in the stdlib but you must supply a sqlite driver, for example one of these: https://github.com/cvilsmeier/go-sqlite-bench However using the stdlib abstraction adds a lot of performance overhead; although it’ll still be competitive with CSV files.

Ok, one additional dependency to your go.mod - big deal. And by builtin I was referring to the database/sql module which was designed for this.

Well the project goal seems to be extreme minimalism and stdlib only, and the choice of human readable data stores and manually editing the user list suggests a goal is to only need `vim` and `sha256sum` for administration

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

#56

This screams regex injection

You might be right, but the only place where regexps are applied in code is for validating resource text fields (which is optional). Those regexps are defined in read-only schemas by the developer (if needed). Schemas are immutable. There seems to be absolutely no connection between the data transmitted over the API (i.e. what user can inject) and regexps. I'm not dismissing the idea that there might be plenty of other possible vulnerabilities in other areas of this toy project.

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

#58
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.

In 2020 Tailscale used a JSON file.

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

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

#59
post #45

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.

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.

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

#60
post #58
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.

In 2020 Tailscale used a JSON file. https://tailscale.com/blog/an-unlikely-database-migration

If you continue reading, you'll see that they were forced to ditch JSON for a proper key-value database.
Post reply on HN