I just deployed a wasm built SQLite with FTS5 enabled and it’s insane what it is capable of. It’s basically elasticsearch entirely on the client. It’s not entirely as robust as ES but it’s like 80% of the way there, and I repeat, it runs on the client side on your phone or any other SQLite supported device

In 2025, pretending that a CSV can be a reasonable alternative to a database because it is "smaller" is just wild. Totally unconscionable.

    - It's plain text
    - It's super easy to diff
    - It's a natural fit for saving it in a git repo
    - It's searchable using standard tools (grep, etc.)
    - It's easy to backup and restore
    - You don't need to worry about it getting corrupt
    - There are many tools designed to read it to produce X types of outputs

I agree on both your main points. It's not like PB has a bunch of cruft and fat to trim. The BD of the project is very aggressive in constraining scope, which is one of the reasons it's so good. The CSV-thing feels like an academic exercise. 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. You probably want to query it so the first thing you need to do here is import the CSV into DuckDB and write a bunch of queries with "WHERE active=1"

The append-only, text csv format you can concatenate to from a script, edit or query in a spreadsheet, and that's still fast because of the in-memory pointer cache, seems like a big win (assuming you're in the target scaling category).

For local use cases this could be useful. Run locally. Do your thing. Edit with Excel or tool of choice.

Also one less dependency.

What’s the other candidate besides pocketbase?

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.

TIL! I enjoy building cloudless apps and have been relying on localstorage for persistence with an "export" button. 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.

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 it allows apps to be local first and potentially even without network access, but allow me to have automatic backups.

If there were something that formalized this a little more, developers could even make their apps in a... Bring Your Own Network... kinda way. Maybe there's already someone doing this?

> 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 be relatively straightforward to do with native applications, but it would be great to be able to do it with web applications that run on the browser

Btw, does Chrome sync local storage across devices when logged in?

Any examples?

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.

or sqlite?

No dependencies apart from the standard library is my guess.

Like 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.

I also tried to make it a bit more flexible: to use `bcrypt` one can provide their own `pennybase.HashPasswd` function. To use SQLite one can implement five methods of `pennybase.DB` interface. It's not perfect, but at the code size of 700 lines it should be possible to customise any part of it without much cognitive difficulties.

Indeed bcrypt is preferred but this is just a simple backend. My first ick was using CSV as storage as opposed to golang’s builtin SQLite support.

A SQLite connection can be made with just a sqlite://data.db connection string.

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

If it's in the examples, it WILL make it to someone's production code

>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)

This one isn't quite saying its cheaper, or even charging, I think you might get a laugh if you click through. I don't think we'll need to worry about the costs being cranked after lock-in.

I always used to feel this about why? But I mean, I've always felt like its the author's choice as to why they are doing this. And we think of it as a binary option (That they want to contribute to some other project or this) but I feel as if we don't think that maybe we had a binary option of this or absolutely nothing.

Now what I do like though is the second line of your post. What are the comparisons... Now IMO, the biggest thing is that this thing is genuinely really tiny (less than 1k loc is wild) and maybe they really followed the occam's razor and just ditched sql and the simplest sql (sqllite) altogether for the sweet csv.

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. Maybe I am going into a tangent but I love sqlite and what pocketbase does tbh. I think of sqlite + per user db and I just get so happy thinking about this architecture tbh. I love sqlite.

To be fair, the project is linked to the blog post I recently wrote, so it's merely a tiny personal/educational project.

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.

I also attempted to make it as small as possible. 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.

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.

Minimalism. It’s tiny and its data can be completely administered with `vim` and `sha256sum`

Given the setup I’d guess it makes sense for little household scale apps w/ a user list in the low tens of people.

>> What does it bring that is not already there in Pocketbase?

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.

Why do you buy/rent your own house instead of joining a house share?