Live data from Hacker News

Which modern databases support ACID transactions?

foundationdb.com

11–20 of 55 posts

Re: Which modern databases support ACID transactions?

#11

> RavenDB uses a weak form of isolation called "snapshot isolation". ... Index updates are not Atomic. If MVCC ( http://en.wikipedia.org/wiki/Multiversion_concurrency_contro... ) is "weak", then are they claiming read/write locks are better? Also, to nitpick, RavenDB's reads/writes in the document storage engine are entirely atomic. A lucene index is maintained in a secondary store which is eventually consistent. But…

As we disclaim on the page itself, we aren't experts on all of these databases, so it's possible that we've made a mistake. We are relying on the documentation of other products (but on the specific documented claims rather than whether they throw around the term "ACID").

'Snapshot isolation' is a level of isolation guarantee, not an implementation technique. It means that a transaction will read values consistently at one point in history and then write values at a later point, even though the read values may change in between. To give a classic example, pure snapshot isolation doesn't allow you to soundly transfer $100 from Alice's account to Bob's account. FoundationDB uses MVCC and optimistic concurrency, but provides serializable isolation.

Besides this, and the asynchronous indexing that you mention, RavenDB uses an "XA" type technique for cross-node transactions which relies on the durability of an external transaction coordinator. Various public statements of the developers lead me to think that they don't find this arrangement more trustworthy than I do.

"Local" transactions on a single document don't qualify as ACID transactions; that's one of the primary messages of the page you are linking to.

Re: Which modern databases support ACID transactions?

#12

It would be nice to see a "NewSQL" database like Clustrix in this comparison. From my understanding of their white papers the transactions are ACID.

We have been told by people who should know that Clustrix does not provide serializable transactions, but since this claim is unspecific and not based on publically available information we haven't put it on the page.

Re: Which modern databases support ACID transactions?

#14

> MySQL provides ACID transactions on a single machine That made me chortle. If you can't roll back an `ALTER TABLE` command (e.g., to back out of a failed schema migration), you don't really have good ACID semantics. Here's a list of other fun MySQL commands that sidestep transactions: http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html

Isn't ALTER TABLE a fundamentally slow and blocking action anyway? It's easy enough to make a new table and swap it in. Transactions for row-level actions are far more important.

Re: Which modern databases support ACID transactions?

#15

What about RethinkDB?

From RethinkDB FAQ (http://www.rethinkdb.com/faq/) "RethinkDB is not a good choice if you need full ACID support or strong schema enforcement — in this case you are better off using a relational database such as MySQL or PostgreSQL."

Re: Which modern databases support ACID transactions?

#16

> MySQL provides ACID transactions on a single machine That made me chortle. If you can't roll back an `ALTER TABLE` command (e.g., to back out of a failed schema migration), you don't really have good ACID semantics. Here's a list of other fun MySQL commands that sidestep transactions: http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html

The property you are looking for - that every SQL command can take place in a transaction - is surely a very desirable property for a SQL database to have, but from my perspective a database can provide genuine ACID transactions even if it only supports a subset of read and write operations within them.

Actually, I think we are giving too much credit to Oracle! There are (relatively subtle, but real) concurrency anomalies in their so-called "serializable" isolation level.

Re: Which modern databases support ACID transactions?

#17

> MySQL provides ACID transactions on a single machine That made me chortle. If you can't roll back an `ALTER TABLE` command (e.g., to back out of a failed schema migration), you don't really have good ACID semantics. Here's a list of other fun MySQL commands that sidestep transactions: http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html

Not even just alter table, it's all DDL, I believe.

This has a way of biting one in the ass in the worst possible moment, during a migration.

Re: Which modern databases support ACID transactions?

#18
I'm afraid there were more 'databases' created in last 2 years than in all earlier history of human civilization. This suggests authors of some of these products have yet to discover what ACID means and how many problems they didn't even think of have already been solved many years ago.

Re: Which modern databases support ACID transactions?

#19

It would be nice to see a "NewSQL" database like Clustrix in this comparison. From my understanding of their white papers the transactions are ACID.

We have been told by people who should know that Clustrix does not provide serializable transactions, but since this claim is unspecific and not based on publically available information we haven't put it on the page.

Apparently as per their docs (http://docs.clustrix.com/plugins/viewsource/viewpagesrc.acti...) this is true specific to end-user transactions: "Note: serializable isolation not currently available to end user transactions."

The Serializeable isolation level is used for data moves within the cluster according to the table referencing isolation levels and row visibility rules.

Re: Which modern databases support ACID transactions?

#20

> MySQL provides ACID transactions on a single machine That made me chortle. If you can't roll back an `ALTER TABLE` command (e.g., to back out of a failed schema migration), you don't really have good ACID semantics. Here's a list of other fun MySQL commands that sidestep transactions: http://dev.mysql.com/doc/refman/5.5/en/implicit-commit.html

Isn't ALTER TABLE a fundamentally slow and blocking action anyway? It's easy enough to make a new table and swap it in. Transactions for row-level actions are far more important.

The ability to do a schema migration consisting of several changes as an all-or-nothing, all-at-once change would be useful even if they can't figure out how to do it concurrently with other operations on the tables.

It shouldn't require too crazy of an implementation to allow reads concurrent with schema modification (seeing the old version of the world) and it's not impossible to allow concurrent, transactional writes too.

Post reply on HN