JSON in Databases

Appreciation for JSON field support in modern databases, arrow functions in SQLite, and DuckDB's superior JSON handling with columnar extraction

The ongoing shift toward SQLite and the pervasive use of JSON fields highlights a growing preference for database simplicity and flexible data structures. SQLite is particularly lauded for its "one-file" convenience and ergonomic arrow functions, which make manipulating flexible data a seamless experience for developers. However, DuckDB is emerging as a powerful alternative for complex tasks, offering superior handling of random JSON through its ability to extract fields into dense columnar representations. Despite these advancements, users are already looking toward the next level of optimization, specifically seeking more granular control over how internal structs are materialized and stored within these columnar frameworks.

View on HN · Topics

From my perspective on databases, two trends continued in 2025:

1: Moving everything to SQLite

2: Using mostly JSON fields

Both started already a few years back and accelerated in 2025.

SQLite is just so nice and easy to deal with, with its no-daemon, one-file-per-db and one-type-per value approach.

And the JSON arrow functions make it a pleasure to work with flexible JSON data.

View on HN · Topics

FWIW (and this is IMHO of course) DuckDB makes working with random JSON much nicer than SQLite, not least because I can extract JSON fields to dense columnar representations and do it in a deterministic, repeatable way.

The only thing I want out of DuckDB core at this point is support for overriding the columnar storage representation for certain structs. Right now, DuckDB decomposes structs into fields and stores each field in a column. I'd like to be able to say "no, please, pre-materialize this tuple subset and store this struct in an internal BLOB or something".

Summarizer