HN Distilled

Essential insights from Hacker News discussions

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

Original Article

Hacker News Discussion

Here's a summary of the themes from the Hacker News discussion:

Minimalism and Simplicity

A core theme is the appreciation for extreme minimalism and simplicity in the project's design, often contrasted with more feature-rich alternatives. This includes a small codebase and a simple approach to data storage.

  • "I like the simplicity of the approach." - Octoth0rpe
  • "Minimalism. It’s tiny and its data can be completely administered with vim and sha256sum" - jitl
  • "So yeah, I don't try to compete with Pocketbase and others, just trying to see what it takes to build a minimally viable backend with a similar architecture." - zserge
  • "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" - jitl
  • "The fact I can't open an SQLite database in my text editor is a little thin, considering many tools are lighter weight than text editors, and "reading" a database (any format) is seldom the goal." - skeeter2020
  • "If it's in the examples, it WILL make it to someone's production code" - ehutch79
  • "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." - riigess

Comparison to Pocketbase and similar projects

Several users draw parallels between this project and Pocketbase, questioning the need for a new project when similar, established options exist. There's also a discussion about the spectrum of emerging simple backend solutions.

  • "I don't understand why create a new project instead of contributing to Pocketbase, which looks very similar. What does it bring that is not already there in Pocketbase?" - miroljub
  • "I've been following trailbase for this purpose as well: https://trailbase.io" - Octoth0rpe
  • "I appreciate how it seems like we have a spectrum of similar options emerging now for simple backends, ranging from pennybase to trailbase to pocketbase." - Octoth0rpe
  • "NIH mostly. A big part of why Pocketbase is so good is because the project is aggressively constrained, both in features and contributions. I'd suggest people contribute to the ecosystem, which is big and growing." - skeeter2020
  • "Pocketbase is already the poor man's BaaS, and is minimalist compared to the two others mentioned." - CharlesW
  • "Firebase, Supabase, Pocketbase" - jonny_eh

Data Storage Format (CSV vs. Alternatives)

A significant portion of the discussion revolves around the project's choice to use CSV for data storage and the implications of this. Many users express skepticism about CSV's suitability for general-purpose databases, advocating for alternatives like SQLite.

  • "Maybe they really followed the occam's razor and just ditched sql and the simplest sql (sqllite) altogether for the sweet csv." - Imustaskforhelp
  • "I never thought there would be a day where I would have to say that sqlite would be the one complex given how in all senses sqlite is like the most simplest / embeddable sql database or databases in general." - Imustaskforhelp
  • "The choice of the "database" is dictated by the very same goals. I deliberately made it an interface, better databases exist and can be plugged in with little code changes. But for starters I went with what Go stdlib offers, and CSV is easy enough to debug." - zserge
  • "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." - pavlov
  • "CSV database is interesting; probably the most trivially-debuggable a database can possibly be. Although why not SQLite? CSV is not very resistant corruption if host crashes midway through a write." - jasonthorsness
  • "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." - CharlesW
  • "Data stored in human-readable CSVs" - CharlesW
  • "In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable." - loeber
  • "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." - r0fl
  • "All these benefits also apply to SQLite, but SQLite is also typed, indexed, and works with tons of tools and libraries." - vineyardmike
  • "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?" - nullishdomain
  • "In hind sight, 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." - zserge

Use of Go Standard Library and Dependencies

The project's reliance on the Go standard library and the implications for dependencies (particularly CGO for SQLite) is a recurring point.

  • "The choice of the "database" is dictated by the very same goals. I deliberately made it an interface, better databases exist and can be plugged in with little code changes. But for starters I went with what Go stdlib offers, and CSV is easy enough to debug." - zserge
  • "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" - jitl
  • "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." - reactordev
  • "maybe this is why they used sha-256 too, it's in the stdlib whereas bcrypt is a package (even if "official")" - fkyoureadthedoc
  • "The standard lib has pbkdf2 though." - ncruces
  • "Most of the more common SQLite implementations for go require CGO and this is a pretty steep request, it's definitely more than a line in go.mod" - gtufano
  • "No dependencies apart from the standard library is my guess." - ncruces
  • "It doesn’t and using the standard 3rd party package requires compiling with CGO which is a pain for cross-platform :(" - jasonthorsness
  • "theoretically there is a go port of sqlite by either using wazero[1] (wasm runtime) and then using sqlite from there or some modernc package2" - Imustaskforhelp
  • "For modernc you gave the correct link. For the wazero based driver, it's this package (I'm the author): https://github.com/ncruces/go-sqlite3" - ncruces
  • "There is a CGO-free package for the basics: https://gitlab.com/cznic/sqlite Not 100% drop-in though. I’ve hit some snags around VFS support." - kassner
  • "As others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work." - zserge

Local-First and Cloudless Applications

The discussion touches on the growing interest in local-first applications and leveraging browser capabilities like the File System Access API to store data locally, reducing reliance on cloud services.

  • "Do we still need a back-end, now that Chrome supports the File System Access API on both desktop and mobile?" - TekMol
  • "This is exactly what I've been looking for. A lot of what I've read about local-first apps included solving for data syncing for collaborative features. I had no idea it could be this simple if all you need is local persistence." - thomascountz
  • "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." - gavmor
  • "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" - nico
  • "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 this allows apps to be local first and potentially even without network access, but allow me to have automatic backups." - gausswho
  • "If there were something that formalized this a little more, developers could even make their apps in a... Bring Your Own Network... kinda way." - gausswho

Password Hashing and Security Concerns

There's a brief but notable exchange about the choice of SHA-256 for password hashing, with several users pointing out that bcrypt is generally preferred for its computational expense.

  • "I haven't had to handle password hashing in like a decade (thanks SSO), but isn't fast hashing like SHA-256 bad for it? Bcrypt was the standard last I did it. Or is this just an example and not what is actually used in the code?" - fkyoureadulershedoc
  • "Indeed bcrypt is preferred but this is just a simple backend." - reactordev
  • "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." - bob1029
  • "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." - bob1029
  • "I am guessing the goal is that the file can be managed more easily with a text editor and some shell utils." - ncruces
  • "As others have guessed, I limited myself to what Go stdlib offers. Since it's a personal/educational project -- I only wanted to play around with this sort of architecture (similar to k8s apiserver and various popular BaaSes). It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work." - zserge

Project Motivation and Scope

The author of the project clarifies that it is a personal, educational, and experimental project, not intended to compete with established BaaS solutions. The focus is on exploring specific architectural concepts with extreme minimalism.

  • "To be fair, the project is linked to the blog post I recently wrote, so it's merely a tiny personal/educational project." - zserge
  • "I tried to experiment with an API similar to what k8s api server offers: dynamic schemas for custom resources, generated uniform REST API with well-defined RBAC rules, watch/real-time notifications, customisation of business logic with admission hooks etc." - zserge
  • "It was never meant to run outside of my localhost, so password security or choice of the database was never a concern -- whatever is in stdlib and is "good enough" would work." - zserge
  • "@ 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?" - riigess