Transactions on Ethereum are atomic. If something throws, everything rolls back.

There's one well-known exception, which is that if your contract sends ETH to another contract, invoking its fallback function, then a throw in the callee just means the call returns false. So in that particular case you have to check the return value and rethrow to make it atomic; this sounds crazy but in some circumstances you don't actually want to throw. The compiler gives you a warning if you don't check.

Didn't the DAO hack happen because someone found a way to make an "atomic" transaction fail without full rollback?

No, it was a reentrant attack. The contract was doing a state change after sending ETH, and since the recipient called back, it was able to get repeated ETH sends before the state updated.

That's an atomicity failure. That class of bug, incidentally, is a classic source of trouble in window/widget GUI systems.

Hah, I used to run into a lot of those GUI issues, and hadn't made the connection until now.

It's a logic error. It's actually still atomic.

To clarify, reentrant errors are not atomicity errors. Fully serializable transactions can have reentrant errors and they often do, but that class of error is a case of the code not doing what you expect rather than an atomic violation.

What I would instead wager is that it's too easy to introduce reentrant errors in Solidity.

I've noticed since the DAO exploit, the ecosystem has been better about this though. For example, Solidity's docs has a section of reentrancy, and even the in-browser editor can warn you about reentrancy in some cases. Seems to be improving, though unfortunately after big expense.

Luckily, while it's easy to introduce reentrant errors, it's also easy to avoid them: just make sure that an ETH transfer or another call to an unknown contract is always the last thing you do in a transaction.

It's sometimes easy to miss, but the ecosystem is also a lot better at insisting on public security audits.

It's not loaded into a SQL database. You can think of Presto as simply as a SQL query engine. It sources data from Ethereum and run queries on it.

not only would it be hard, but using a blockchain (a type of database) to represent a functional SQL database using smart contracts is a mind-numbingly bad idea.

(insert "should i use a blockchain" infographic, which is amusingly impossible to google image search for, because this question evidently does not often occur to people...)

That might just depend on what parts of a "SQL database" you'd implement using a blockchain, and on the application type. You could e.g. segregate the data and only use the blockchain to authorize or timestamp transactions, for instance. In the latter case, Blockchain is just another consensus layer, and all distributed databases need one. See also https://github.com/pixelspark/catena, which uses the blockchain like a replication journal, logging only mutating queries and providing authorization based on public key crypto (disclosure: I am the author).

not to put too fine a point of it, but there's a world of difference between creating a ledger that creates a "distributed" SQL database whose integrity is guaranteed among non-trusted nodes through a blockchain, and using smart contracts to "put a functioning SQL database on the blockchain."

"get used to blockchain when all you know is SQL" - cool.

"guarantee all us non-trusted nodes have the same SQL database" - ...sure, but for any project such that i want this, i'm pretty sure i don't need a blockchain. (but of course, your project doubtless has uses i haven't thought of)

"i want a trustless SQL database so i'm going to use EVM and solidity and put it on The Blockchain because i'm awesome" - very bad.

"i'm starting a new project, so naturally i need to use a blockchain" - extremely bad.