Live data from Hacker News

Which modern databases support ACID transactions?

foundationdb.com

21–30 of 55 posts

Re: Which modern databases support ACID transactions?

#22

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

heh, this applies to all 'new' databases - if you aren't sure which one to choose, you're usually better off staying with a relational. You'll be bleeding edge in few years when SQL is forgotten and then re-discovered.

Re: Which modern databases support ACID transactions?

#24

> 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

MySQL isn't the only engine that does this.

http://docs.oracle.com/cd/E17952_01/refman-5.1-en/implicit-c...

Edit - I was wrong!

Not only did I link to the wrong docs, but Oracle fixed what I considered to be a longstanding bug.

Thanks to those who pointed it out.

For a very, very long time, Oracle has enforced implicit transaction boundaries around DDL, and it is about time that finally changed.

Re: Which modern databases support ACID transactions?

#28

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

It happens to be a slow and blocking action on MySQL, yes. That's yet another problem with MySQL. You can only make a new table and swap it in if you can stop writing to your old table, or don't care if records go missing. I've lost weeks trying increasingly convoluted methods to get an online schema migration safely in MySQL, with no satisfying conclusion. You can sometimes get away with pt-online-schema-change's method of adding triggers to copy new rows while copying over the existing table contents, but that failed pretty badly for us because of collisions with the innodb gap lock on the table, so we ended up having to do multiple passes, populating the new table once without the live updates, then copying it over again while the live updates were copied over with triggers. It was a mess.

Re: Which modern databases support ACID transactions?

#29
post #23

We use MySQL-Galera and it has full ACID guarantees in cluster/multi-site/DR environment. Unfortunately the article is not a complete overview of the existing DBs landscape and has too much marketing in other places as well.

I know very little about Galera replication, but its FAQ states that it provides only snapshot isolation.

You are certainly correct that we have not provided a complete overview of the DB market! That is a very ambitious project. We built this page largely to call out the use of "ACID" terminology by vendors that don't actually provide it.

Re: Which modern databases support ACID transactions?

#30

> 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

ACID refers to actions that can take place within a transaction. Transactions refer to logical operation to the data. The data is the content, not de container. DML affects content, DDL affects the container. ALTER TABLE is a DDL operation.

Now, I know that _some_ databases offer some level of support to include DLL operations within a transaction, but its far from being common, and most of the implementations are quite recent.

Post reply on HN