Ooh, I'll bite! For one, they're different data models. FaunaDB is a document store, so records are fundamentally trees, whereas SQL is oriented around processi

Ooh, I'll bite! For one, they're different data models. FaunaDB is a document store, so records are fundamentally trees, whereas SQL is oriented around processing tuples. FaunaDB records have queryable metadata; SQL rows (I think?) don't. You can extend SQL (look at JSON support in Postgres) to deal with arrays and maps as core datatypes, but a special-purpose language can be better suited to the purpose. Second, FaunaDB's transactional model precludes interactive transactions, whereas SQL transactions are designed for interactive use. Imagine if every transaction was a stored procedure--that's the query structure you'd be looking at. It's certainly possible to do, but stored procedures are sort of an imperative language grafted on to the relational algebra of SQL, and support isn't as standardized as SQL's core. Third, FaunaDB is a temporal store--you can ask for the state of any query at any point in time, and even mix temporal scopes in the same query expression. SQL doesn't have a first-class temporal model. In general, using SQL offers advantages, including user familiarity, code reuse, and easier migration from other SQL stores. None of the things FaunaDB does are impossible to express in SQL, and they have been tackled by various DBs' extensions to SQL, but the familiarity+reuse advantages aren't as applicable once you start thinking about the distinct properties of FaunaDB's data model.