from Hacker News

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

by dcu on 7/3/25, 3:35 PM with 125 comments

  • by CharlesW on 7/3/25, 5:03 PM

    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.

  • by TekMol on 7/3/25, 4:05 PM

    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 all browsers support. Fortunately it has the same API, so implementing it was no additional work. Only downside is that it cannot put files in a user selected directory. So in that mode, I support a backup via an old-fashioned download link.

    This way, users do not have to put their data into the cloud. It all stays on their own device.

  • by pavlov on 7/3/25, 4:38 PM

    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.

  • by jasonthorsness on 7/3/25, 4:39 PM

    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.
  • by fkyoureadthedoc on 7/3/25, 4:07 PM

    > 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 have user ID which is user name, version number (always 1), salt for password hashing, and the password itself (hashed with SHA-256 and encoded as Base32). The last column is a list of roles assigned to the user.

    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?

  • by Octoth0rpe on 7/3/25, 4:03 PM

    I like the simplicity of the approach. I've been following trailbase for this purpose as well: https://trailbase.io

    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. I do hope one of them eventually implements postgres as an alternative to sqlite at some point though.

  • by LikeBeans on 7/4/25, 1:22 PM

    I think that's a neat idea. I often use Google Sheets as a database for my projects. I read 'setup' data and 'log' data. Works well. Most often just append a row at the end for writing. But I can see why a CSV can be a decent idea too especially if it can be edited with a spreadsheet app. So I would put this on a server (a file share) and edit it as needed with Excel/Numbers/Google Sheets etc... and click save. My apps can read it and if writing appends a line then hurray! cool idea.
  • by MattDaEskimo on 7/3/25, 5:00 PM

    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.

  • by tra3 on 7/3/25, 4:12 PM

    This is neat. Ruby on Rails -> Serverless (Firebase/Heroku/etc) -> Pocketbase etc?

    What kinds apps are folks building with this? Are there any decently sized websites running on Pocketbase/trailbase?

  • by miroljub on 7/3/25, 4:04 PM

    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?
  • by desireco42 on 7/3/25, 11:16 PM

    I find Manifest.js really gives me that minimalist feel that you are going for here.

    I would find it more palatable if format was JSON or YML or ideally TOML right...

    It is definitely interesting what you are doing and you know, thanks for sharing. Not for everyone but good to see what and how people are thinking.

  • by steveharman on 7/3/25, 5:46 PM

    Self host Convex https://convex.dev ?
  • by ShayNehmad on 7/3/25, 5:53 PM

    Mentioned on this week's Cup o Go episode. Cool fun toy project.
  • by atentaten on 7/3/25, 4:50 PM

    Can it do joins? I may have missed it in the doc.
  • by ivanjermakov on 7/3/25, 4:07 PM

    "Back End-as-a-Service" in the title is confusing. Consider adhering to the original project description.
  • by TiredOfLife on 7/3/25, 4:17 PM

    Or use something that has been used in production for decades like Laravel, Rails, Django or even Spring.
  • by ardme on 7/4/25, 4:24 AM

    why would you not use sqlite?
  • by codefeenix on 7/4/25, 4:51 AM

    BEasS
  • by theyknowitsxmas on 7/3/25, 4:27 PM

    This screams regex injection
  • by jonstaab on 7/3/25, 5:32 PM

    Alternatively, you could use nostr, have your users pay for the database, and get access to rich content types, an existing social graph, and application interoperability.
  • by animitronix on 7/3/25, 4:47 PM

    Sorry, that acronym is already in use for banking as a service. Try again.
  • by riigess on 7/3/25, 7:21 PM

    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.