> Following the Aurora recommendations would lead to a minimum marginal cost of over $1,050 per customer to achieve performance and security isolation at the database level.

Where does the $1,050 come from?

It comes from the minimum ACU requirement per isolated cluster.

Even if scale to zero is eventually supported, some minimum capacity will still be required to avoid cold start latency.

> However, Fauna has five big architectural differences from Aurora and from other RDBMSes:

> Fauna is programmable, with a rich standard library of functions. It can run transactional business computation adjacent to the data and let the developer compose computational logic in a maintainable way.

I appreciate programming in PL/SQL isn't great or anything, but it exists and it works and I've used it to great effect in projects where the client pretty much only ever works with stored procedures, and I thereby don't really understand if they are actually different in fundamental ability here or if they merely have a better language (which I would even then question, as I have totally taken advantage of the ability to program PostgreSQL stored procedures in PL/Python).

They admit it's an apples-oranges comparison, so why do it?

I mean, isn't Fauna more directly comparable to Dynamo than Aurora?

We get people asking about it because they are both serverless—-it’s not like there’s a lot of serverless databases on the market.

Dynamo is indeed closer and there is a comparison here: https://fauna.com/blog/comparing-fauna-and-dynamodb-pricing-...

Apples and oranges are still fruit.

(off topic) in russian instead of "comparing apples and oranges" idiom we have "comparing a warm [object] to a soft [one]"

In Serbian, we have "babe i zabe" - grandmas and frogs :D

I just dislike the syntax in Fauna:

var createP = client.query( q.Create( q.Collection('test'), { data: { testField: 'testValue' } } ) )

https://docs.fauna.com/fauna/current/drivers/javascript

Why those capitalized functions names .Create() and .Collection()? Also the fact that you have to pass around that q. Maybe that could be changed with: let { Create, Collection} = q

I care about the syntax of the libraries I use and Fauna seems clumsy.

I dislike the `q.` too, for many reason. One of which is it's not copy/paste friendly from code to Shell.

But it's just sugar, I basically write it the way you mentioned, by deconstructing `q`. See https://github.com/Vadorequest/rwa-faunadb-reaflow-nextjs-ma...

Fauna has no native syntax, instead it has language-specific DSLs. This helps with type safety and query composability but it does indeed lead to awkward syntactical situations when the host language and Fauna semantics don’t quite align.

The snippet in the grandparent post is JavaScript; is there an ORM or other library that has an example of an idiomatic JS or Typescript syntax that either of you would prefer?

I’ve really enjoy writing queries in RethinkDB’s [REQL language](https://rethinkdb.com/docs/introduction-to-reql/)

> ‘r.table(“users”).filter(u => u(“email”).match(“.*@gmail.com$”)).run(conn)’

Knex syntax (http://knexjs.org/) is reasonable. It's basically method chaining.

mongodb is so well integrated with Javascript and JSON. db.collection().find({}) is just so fluent.

I find all those capitalized functions in Fauna weird. In most C based languages like Javascript functions are lowercase.

Would it be possible for the Fauna JS wrapper to also accept lowercased functions?

any idea how to lowercase all those capitalized functions?

> Maybe that could be changed with: let { Create, Collection} = q

Yeah, I do that all the time. It makes FQL code much cleaner.

Capitalized method names are pretty common

Indeed. Maybe not in the JS world though.

Its an interesting product. For someone using Aurora Postgres though, it leaves lots of unanswered questions about compatibility. This page they link to is basically a landing page with no details: https://fauna.com/postgres.

My read on this is "if you already use postgres don't migrate, but if you want to use us for a new application that is a good fit."

> It offers GraphQL and FQL (Fauna Query Language) interfaces instead of SQL.

I hate that it's this way but it is: all software-aware companies I've worked for won't look at something they can't attach at least a clunky, slow as all hell SQL interface too. And any overhead to do that doesn't make business sense.

There is no comparison really possible here. One supports MySql/Postgres SQL syntax and the other support GraphQL and a made up QL. This "comparison" is really only useful for greenfield development.

It is primarily an architectural and operational comparison.

Does Fauna support inner joins yet?

I understand that companies with enormous data sets can't afford to use joins at all, but I've yet to work somewhere where a properly indexed RDS/Aurora db wasn't able to make use of them just fine. Almost all of my queries beyond simple CRUD reads rely heavily on inner/right joins, and last time I spoke with someone at Fauna, they said that their query logic wouldn't be able to support what my query was doing.

I'm rooting for DB alternatives, but unless a new contender can be as unconstrained as an RDBMS, it's very hard to move.

> Does Fauna support inner joins yet?

You can achieve the same thing, although maybe not in the way you're expecting since FQL is not SQL.

See this introduction I wrote about joins in Fauna:

https://fauna.com/blog/core-fql-concepts-part-5-joins#replic...

Have the latencies of Fauna improved? It used to be 1-100ms range [0] for a query which is absolutely not the same ballpark to compare to any existing database as they usually are an order of magnitude lower but that also probably because they don’t use HTTP which I understand Fauna uses.

[0]: https://news.ycombinator.com/item?id=19311487