> 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.
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.
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?
> 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.
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."
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.
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.
> 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).
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.
25 comments
[ 1.6 ms ] story [ 82.9 ms ] threadWhere does the $1,050 come from?
Even if scale to zero is eventually supported, some minimum capacity will still be required to avoid cold start latency.
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.
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...
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 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?
> ‘r.table(“users”).filter(u => u(“email”).match(“.*@gmail.com$”)).run(conn)’
Yeah, I do that all the time. It makes FQL code much cleaner.
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.
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."
I mean, isn't Fauna more directly comparable to Dynamo than Aurora?
Dynamo is indeed closer and there is a comparison here: https://fauna.com/blog/comparing-fauna-and-dynamodb-pricing-...
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.
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...
> 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).
[0]: https://news.ycombinator.com/item?id=19311487