5 ms·
Transactional databases are not really the best tool for writing tons of (presumably) immutable records. Why are you using it for this? Why not Elastic?
by dumbfounder 1y ago
Transactional databases are not really the best tool for writing tons of (presumably) immutable records. Why are you using it for this? Why not Elastic?
- incoming1211 1y agoBecause transactional databases are perfectly fine for this type of thing when you have 0 to 100k users.
- 0xbadcafebee 1y agoThe total number of users in your system is not a performance characteristic. And transactions are generally wrong for write-heavy anything. Further, if you can just append then the transaction is meaningless.
- incoming1211 1y agoMost systems are based on the number of users performing operations on the application. Majority of people on HN never work on anything with more than 100k users, yet they introduce mountains of infrastructure and blame cloud for being expensive when they never needed that infrastructure to begin with.
- dumbfounder 1y agoThe article is about scaling issues with tons of writes, which I referenced by saying “tons of writes”. Yes, if there is no reason to scale it up you can just use a database. But that’s not the context.
- Kwpolska 1y ago[citaiton needed]
- immibis 1y agoTransactional databases are great, provided your write workload is low enough to fit on one server. If you have to scale up past that, you might have to use a different kind of database. But if transactions work for you, as they do for 99% of small-medium sites, they're amazing. Multi-master transactional databases are an open area of research, as far as I'm aware, but read-only replication is a solved problem. Therefore your write traffic, including your transaction overhead, has to fit within one server's capacity, while your read traffic can scale horizontally as much as you like.