21–30 of 196 posts
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/datomic-is-free.html (2023)
The author mentions about it in the name change for edgeDb to gel. However, it could also have been added in the Acquisitions landscape. Gel joined vercel [1]. 1. https://www.geldata.com/blog/gel-joins-vercel
[1] https://vercel.com/blog/investing-in-the-python-ecosystem
Earlier quoted context omitted.
Why have multiple connections in the first place? If your writes are fast, doing them serially does not cause anyone to wait. How often does the typical user write to the DB? Often it is like once per day or so (for example on hacker news). Say the write takes 1/1000s. Then you can serve 1000 * 60 * 60 * 24 = 86 million users And nobody has to wait longer than a second when they hit the "reply" button, as I do now ..…
> If your writes are fast, doing them serially does not cause anyone to wait. Why impose such a limitation on your system when you don't have to by using some other database actually designed for multi user systems (Postgres, MySQL, etc)?
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.
Pardon my ignorance, yet wasn't the prevailing thought a few years ago that you would never use SQLite in production? Has that school of thought changed?
If you’re at a point where the application needs to talk over a network to your database then that’s a reasonable heuristic that you should use a different DB. I personally wouldn’t trust my data to NFS.
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.
As a backend database that's not multi user, how many web connections that do writes can it realistically handle? Assuming writes are small say 100+ rows each? Any mitigation strategy for larger use cases? Thanks in advance!
It has been OK so far, but definitely I will have to migrate to Postgres at one point, rather sooner than later.
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.
Pardon my ignorance, yet wasn't the prevailing thought a few years ago that you would never use SQLite in production? Has that school of thought changed?
1. People gaining newfound appreciation of having the database on the same machine as the web server itself. The latency gains can be substantial and obviously there are some small cost savings too as you don't need a separate database server anymore. This does obviously limit you to a single web server, but single machines can have tons of cores and serve tens of thousands of requests per second, so that is not as limiting as you'd think.
2. Tools like litestream will continuously back up all writes to object storage, so that one web server having a hardware failure is not a problem as long as your SLA allow downtimes of a few minutes every few years. (and let's be real, most small companies for which this would be a good architecture don't have any SLA at all)
3. SQLite has concurrent writes now, so it's gotten much more performant in situations with multiple users at the same time.
So for specific use cases it can be a nice setup because you don't feel the downsides (yet) but you do get better latency and simpler architecture. That said, there's a reason the standard became the standard, so unless you have a very specific reason to choose this I'd recommend the "normal" multitier architectures in like 99% of cases.
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…
Earlier quoted context omitted.
Pardon my ignorance, yet wasn't the prevailing thought a few years ago that you would never use SQLite in production? Has that school of thought changed?
Only for large scale multiple user applications. It’s more than reasonable as a data store in local applications or at smaller scales where having the application and data layer on the same machine are acceptable. If you’re at a point where the application needs to talk over a network to your database then that’s a reasonable heuristic that you should use a different DB. I personally wouldn’t trust my data to NFS.
Earlier quoted context omitted.
As a backend database that's not multi user, how many web connections that do writes can it realistically handle? Assuming writes are small say 100+ rows each? Any mitigation strategy for larger use cases? Thanks in advance!
After 2 years in production with a small (but write heavy) web service... it's a mixed bag. It definitely does the job, but not having a DB server does have not only benefits, but also drawbacks. The biggest being (lack of) caching the file/DB in RAM. As a result I have to do my own read caching, which is fine in Rust using the mokka caching library, but it's still something you have to do yourself, which would other…
In my experience, caching makes most sense on the CDN layer. Which not only caches the DB requests but the result of the rendering and everything else. So most requests do not even hit your server. And those that do need fresh data anyhow.
Earlier quoted context omitted.
Only for large scale multiple user applications. It’s more than reasonable as a data store in local applications or at smaller scales where having the application and data layer on the same machine are acceptable. If you’re at a point where the application needs to talk over a network to your database then that’s a reasonable heuristic that you should use a different DB. I personally wouldn’t trust my data to NFS.
What is a "local application"?
Local as in "desktop application on the local machine" where you are the sole user.