[floatingatoll]

Transactions let you perform any series of SQL commands with various expectations around data safety and locking guarantees depending on isolation level.

Batch writes provide a tiny subset of the full possibilities of transactions. While sufficient in many cases, that cannot be generalized to "LevelDB supports transactions".

[romed]

That's just your pet definition of transaction. That is not universally accepted.

[barrkel]

Atomicity and consistency. The classic case is balance transfer. Batch writes only cope with this to the degree that you can model your computation purely in database primitives that can execute server-side as part of the batch. If your computation involves anything else, such as external data or a computation that can't be modelled, then microbatches aren't good enough: you risk lost updates and inconsistent reads.

[floatingatoll]

Universal acceptance is not a valid criterion for human beings at scale.

Schizophrenic people don’t accept facts like “this wall exists”, yet we still reach agreement as a society that a wall exists and don’t try to walk through walls because they exist.

You are of course welcome to hold any belief you wish, but believing something that puts you in direct contradiction to an entire industry significantly raises the bar of proof you must provide in order to convince others to listen to you.

Your reply does not provide that proof, and thus your argument is not persuasive.

[Twirrim]

I would love to see an example of someone actually knowledgeable about databases who has a different definition for transaction.

[erpellan]

Atomicity, consistency, isolation, durability.

https://en.wikipedia.org/wiki/ACID_(computer_science)

But that's just like, the industry's opinion, man.

[Twirrim]

Maybe I completely misunderstood the parents description of a transaction, but that was exactly what they were saying.