Live data from Hacker News

Databases in 2025: A Year in Review

cs.cmu.edu

191–196 of 196 posts

Re: Databases in 2025: A Year in Review

#191
post #170

Earlier quoted context omitted.

> SQLite has concurrent writes now Just to clarify: Unless I've missed something, this is only with WAL mode and concurrent reads at the same time as writes, I don't think it can handle multiple concurrent writes at the same time?

As I understand it, there can be concurrent writes as long as they don't touch the same data (the same file system pages, to be exact). Also, the actual COMMIT part is still serialized and you need to begin your transactions with BEGIN CONCURRENT. If two transactions do conflict, the later one will be forced to ROLLBACK although you can still try again. It is up to the application to do this. See also https://www.sql…

Also just a note: BEGIN CONCURRENT is not in mainline SQLite releases. You need to build your own from a branch. Not a huge deal but just something to note.

Re: Databases in 2025: A Year in Review

#192
post #9

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.

For as much talk as I see about SQLite, are people actually using it or does it just have good marketers?

Do you have a specific use case you're curious about? It's the most widely deployed database software of all time. https://sqlite.org/mostdeployed.html

Re: Databases in 2025: A Year in Review

#193

Earlier quoted context omitted.

People are slow to realize the benefit of immutable databases, but it is happening. It's not just auditability; immutable databases can also allow concurrent reads while writes are happening, fast cloning of data structures, and fast undo of transactions. The ones you mentioned are large backend databases, but I'm working on an "immutable SQLite"...a single file immutable database that is embedded and works as a libr…

How do you deal with deletion requirements in a immutable database? Like how do you delete personal data when requested?

In the case of Datomic: https://docs.datomic.com/operation/excision.html

Re: Databases in 2025: A Year in Review

#194
post #21

While the author mentions that he just doesn't have the time to look at all the databases, none of the reviews of the last few years mention immutable and/or bi-temporal databases. Which looks more like a blind spot to me honestly. This category of databases is just fantastic for industries like fintech. Two candidates are sticking out. https://xtdb.com/blog/launching-xtdb-v2 (2025) https://blog.datomic.com/2023/04/d…

Btw Datomic is free now that Nubank supports it (and runs a large bank on it).

There's also a fantastic kind of mini, FOSS, file-based Datomic-style Datalog DB that's not immutable called Datalevin. Uses the hyper-fast LMDB under the hood. It's called Datalevin. https://github.com/juji-io/datalevin

Re: Databases in 2025: A Year in Review

#195

Interesting article and I've enjoyed reading all the comments. The focus on Postgres is fascinating to me. From an analytics database perspective, we've had great success with Exasol, which isn't so well known in the US. It is very low overhead (no index management) and extremely fast and scalable. They have a free version as well as a licensed MPP version -- cloud hosted or on-prem. It is a blank slate, but it can d…

For analytics workloads, Exasol is a great choice: high performance & MPP scale. They offer a free Personal Edition for download and testing (cloud and on‑prem options available): https://downloads.exasol.com/exasol-personal worth a quick benchmark with your own data.

Re: Databases in 2025: A Year in Review

#196

Earlier quoted context omitted.

Why? Sqlite and LMDB make fantastic use of it. For anyone doing a single writer db it's a no brainer. It does so much for you and it does it very well. All the things you don't have to implement because it does it for you: - Reading the data from disk - Concurrency between different threads reading the same data - Caching and buffer management - Eviction of pages from memory - Playing nice with other processes in the…

Fun footnote: SQLite only got on board with mmap after I demonstrated how slow their code was without it. I.e., getting a 22x speedup by replacing SQLite's btree code with LMDB https://github.com/LMDB/sqlightning

Thank you for beating the mmap drum and LMDB! It's truly an incredible piece of tech.
Post reply on HN