I am using SQLite as document db for a side project for years now. Made a custom repository base class that can also store blobs in separate columns, so this type of data is not part of the json document. Today there is also jsonb [1], as far as I remember all functions work the same for json and jsonb.

Also the repo class stores write and delete timestamps as separate columns so I can have CDC. CDC is used for building cached view models and is pushed to object storage every 5 minutes for backup as NDJSON. Another process on home server is restoring the db every couple of minutes for second backup and ready to use DB in case it's needed.

I know there are things like Litestream, I wanted something in process and something that can send alerts on failed backups.

[1] https://sqlite.org/jsonb.html

Why don’t you use MongoDB? MongoDB is web scale.

https://youtu.be/b2F-DItXtZs?is=HlayyJ_DPb8NzbS4

(lol! couldn’t resist)

Why do people say document database when they really just mean json database?

> it added a killer feature: generated columns

It would be super cool if somehow SwiftData could translate computed properties of @Model objects into these generated columns via the #Expression macro!

Is this not similar to what Simon Willison has written about before?

https://sqlite-tutorial-pycon-2023.readthedocs.io/en/latest/...

https://simonwillison.net/2021/Jul/28/baked-data/

obviously the example is contrived, but it seems strange me that they are not storing the json in its own column - just extracting a single key from it and storing in a generated column. Why not do that in the app code if youre just going to discard the rest of the json?

Here's an example i saw yesterday from mariadb, which is improving its json support in its upcoming releases.

https://mariadb.com/docs/server/ha-and-performance/optimizat...

``` CREATE TABLE t1 (json_data JSON); INSERT INTO t1 VALUES('{"column1": 1234}'); INSERT INTO t1 ... ```

In order to do efficient queries over data in JSON, you can add a virtual column, and an index on that column:

``` ALTER TABLE t1 ADD COLUMN vcol1 INT AS (cast(json_value(json_data, '$.column1') AS INTEGER)), ADD INDEX(vcol1);

```

    CREATE TABLE t1 (data JSONB);
    INSERT INTO t1 VALUES ('{"column1":1234}');
    CREATE INDEX t1column1 ON t1(data->'column1');
    SELECT * FROM t1 WHERE data1->'column1' = '1234'; // not sure about data type

I do that in psql and it works really well. But your post got me thinking since I need to find a solution to store content of multiple documents, have a way to do FTS as well as vector similarity. I dont need that for all of the documents at once - I need to do it either for one document or at most couple of documents.

Now I'm thinking I could have a separate database file per "batch", store it in object storage and then download on demand and query it as I want. This way I'll not bloat my primary storage size as well as I dont need a special vector DB since sqlite vector search will be enough for up to 50k vectors.

I developed an application using zope on the backend and extjs (now Sencha) and SQLite on the front end in 2009. The form + data was stored as strings in the database and then synced to back-end when connected to the internet. It was targeting remote doctors in third world countries who were often offline. Several doctors at that time had told me they wanted to store the medical data in the same format as the intake form mostly because that was what they were used to with paper forms. Soon after, there was a big push for medical ERP and relational databases won over document databases. I bet it would be much easier to build an application like that now (data stored and displayed in same format as collected) but wonder what market would use it.

I created `kindstore` for exactly this (only supports Bun currently). I never promoted the project until this comment. Curious if anyone is intrigued?

https://github.com/alloc/kindstore

A long time ago, I wrote an ORM to serialize/deserialize object data seamlessly into SQLite, with massive arrays of floats being stored as blobs.

In code, I could effectively mark which class members need to be stored/restored, and optionally provide a custom serialization function for them if needed.

The latter was effectively never necessary, because all the bases types and multi-dimensional arrays were handled by templates.

Really wish I open-sourced that thing then, but the corporate bureaucracy around that was tricky.

I remember sufficiently little about implementation details now that I think I can get to writing it again, without producing a copypasta of that code - and maybe I should :)

I'm doing both "documents" and documents (JSON and gzip compressed blobs for emails, office docs, etc.), with the plaintext extracted and run through FTS5. I can't think of another database that would let me do this, plus vector indexing as well.

JSON extensibility and virtual columns help _a lot_ with variable metadata.

Since sqlite people are probably in this thread - why is storing genomic data as a sqlite tar with all the metadata you want in tables a “Bad Idea” (tm)? Like toss a fastq or bam plus all the downstream data, grant info, experiment parameters, specimen info etc etc in a single file easily parsable.

If you applying NOT NULL constraint, why not extract it from json altogether as a separate column? What's the use of it in json?

You may construct it back on retrieval, if you need it in results.

In my personal project (a game) I use an indexed key + a JSONB to store the save state, which comes from Lua.

So I can have cassette.propxyz = {1, 2, “abc”, true}

And

local anotherprop = cassette.leprop

I remember this getting to the top of HN for at least two more times.

Is this new or something? Works amazing as a document backend.

> (Aside: The hard bit may be getting a new enough SQLite, at the time of writing Homebrew on macOS has it, else you likely need to use an unstable source like nixpkgs-unstable.)

Or just download the source and build it! (Gasp!)

The 1st edition CouchDB book from 2010 explained it like this:

> We write software to improve our lives and the lives of others. Usually this involves taking some mundane information—such as contacts, invoices, or receipts—and manipulating it using a computer application. CouchDB is a great fit for common applications like this because it embraces the natural idea of evolving, self-contained documents as the very core of its data model.

> Self-Contained Data

> An invoice contains all the pertinent information about a single transaction—the seller, the buyer, the date, and a list of the items or services sold. As shown in Figure 1, “Self-contained documents”, there’s no abstract reference on this piece of paper that points to some other piece of paper with the seller’s name and address. Accountants appreciate the simplicity of having everything in one place. And given the choice, programmers appreciate that, too.

> Yet using references is exactly how we model our data in a relational database! Each invoice is stored in a table as a row that refers to other rows in other tables—one row for seller information, one for the buyer, one row for each item billed, and more rows still to describe the item details, manufacturer details, and so on and so forth.

https://guide.couchdb.org/editions/1/en/why.html

Iow, a document database stands in contrast to a relational db in that these JSON things we store in them are more stand-alone “documents” compared to storing data in rows and columns in a relational db like PostgreSQL or SQLite.

It's a MongoDBism. The MongoDB community used document to mean the nonrelational equivalent of a row in a relational database. But over time there was definitional shift, and now it means a JSON blob, even if that blob is in a relational database.

The "document" is sort of the native data type, Put everything in a big hierarchical structure, It is very flexible but analytics across the set can suffer. "relational" is another way to store data, break your big hierarchy into sets of related rows and store the rows as a table, If I were to describe it in geometric terms where the document is a report on a paper, the relation is a vertical slice through a stack of those reports. This is slightly non-intuitive but provides for interesting analysis opportunities.

But nothing prevents you from treating your relational database as a document database, set it up as a key-value store where each key is is the document title and each value is a large blob of document data. If your documents are fairly consistent it is also easy enough to build indexes and query features to regain some of the analytical ability of relational data.

1) The internal or wire representation of data from document DBs isn't necessarily JSON, though it's normally converted to such.

2) "Document" has undergone a bit of semantic drift thanks to HTML and XML. In an informational context it means "structured, hierarchical unit of data containing mostly text". The data from forms, invoices, and the like needs to be collected and stored, even if it isn't properly normalized and relationalized (or is en route to being such) so a "document database" is thought to be suited to this task

I dunno, whatever, I'm in the "just fucking use postgres until you can justify why you shouldn't" camp.

JSON is just a textual representation of the internal data structures.

I think it originates with the early web. JSON being a replacement for XML, and "document" being the general description for the response to a web server.