Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Databases in 2025: A Year in Review

cs.cmu.edu

Post reply on HN
Print view View original

51–60 of 196 posts

Re: Databases in 2025: A Year in Review

#51

Post by pixelesque »

WJW wrote: post #26
andrewinardeer wrote: post #11

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?

SQlite as a database for web services had a little bit of a boom due to: 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 core…

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

Re: Databases in 2025: A Year in Review

#52

Post by kopirgan »

TekMol wrote: post #15
kopirgan wrote: post #12

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!

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

That depends on the use case. HN is not a good example. I am referring to business applications where users submit data. Ofc in these cases we are looking at 00s not millions of users. The answer is good enough.

Re: Databases in 2025: A Year in Review

#53

Post by kopirgan »

withinboredom wrote: post #38
frje1400 wrote: post #31

Earlier quoted context omitted.

So in this solution, you run the backend on a single node that reads/writes from an SQLite file, and that is the entire system?

Thats basically how the web started. You can serve a ridiculous number of users from a single physical machine. It isn't until you get into the hundreds-of-millions of users ballpark where you need to actually create architecture. The "cloud" lets you rent a small part of a physical machine, so it actually feels like you need more machines than you do. But a modern server? Easily 16-32+ cores, 128+gb of ram, and hund…

I agree...there is scale and then there is scale. And then there is scale like Facebook.

We need not assume internet FB level scale for typical biz apps where one instance may support a few hundred users max. Or even few thousand. Over engineering under such assumptions is likely cost ineffective and may even increase surface area of risk. $0.02

Re: Databases in 2025: A Year in Review

#54

Post by giovannibonetti »

pixelesque wrote: post #51
WJW wrote: post #26

Earlier quoted context omitted.

SQlite as a database for web services had a little bit of a boom due to: 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 core…

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

I think only Turso — SQLite rewritten in Rust — supports that.

Re: Databases in 2025: A Year in Review

#55

Post by postexitus »

falcor84 wrote: post #44
anonymousDan wrote: post #27

Earlier quoted context omitted.

Why fintech specifically?

I would assume that it's because in fintech it's more common than in other domains to want to revert a particular thread of transactions without touching others from the same time.

Not only transactions - but state of the world.

Re: Databases in 2025: A Year in Review

#56

Post by kopirgan »

loxs wrote: post #25
kopirgan wrote: post #12

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…

I am no expert, but SQLite does have in memory store? At least for tables that need it..ofc sync of the writes to this store may need more work.

Re: Databases in 2025: A Year in Review

#57

Post by pjmlp »

sandos wrote: post #36
pjmlp wrote: post #20

Over here, it is DB2, SQL Server or Oracle if using a plain RDMS, or whatever DB abstraction layer is provided on top of a SaaS product, where we get to query with some kind of ORM abstraction preventing raw SQL, or GraphQL, without knowing the implementation details.

This sounds like a flashback to J2EE. Which I know is still alive and well. Banks, insurance companies and the tax agency do not much care for fancy new stuff, but that it works.

Yep, Fortune 500 enterprise consulting, boring technology that pays the bills.

Java, .NET, C++, nodejs, Sitecore, Adobe Experience Manager, Optimizely, SAP, Dynamics, headless CMSes,...

Re: Databases in 2025: A Year in Review

#58

Post by autogn0me »

delichon wrote: post #40
beders wrote: 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…

I see people bolting temporality and immutability onto triple stores, because xtdb and datomic can't keep up with their SPARQL graph traversal. I'm hoping for a triple store with native support for time travel.

Lance graph?
Post reply on HN