> <i>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.</i><p>Where does the $1,050 come from?
> However, Fauna has five big architectural differences from Aurora and from other RDBMSes:<p>> 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.<p>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).
I just dislike the syntax in Fauna:<p>var createP = client.query(
q.Create(
q.Collection('test'),
{ data: { testField: 'testValue' } }
)
)<p><a href="https://docs.fauna.com/fauna/current/drivers/javascript" rel="nofollow">https://docs.fauna.com/fauna/current/drivers/javascript</a><p>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<p>I care about the syntax of the libraries I use and Fauna seems clumsy.
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: <a href="https://fauna.com/postgres" rel="nofollow">https://fauna.com/postgres</a>.<p>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.<p>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.
Does Fauna support inner joins yet?<p>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.<p>I'm rooting for DB alternatives, but unless a new contender can be as unconstrained as an RDBMS, it's very hard to move.
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.<p>[0]: <a href="https://news.ycombinator.com/item?id=19311487" rel="nofollow">https://news.ycombinator.com/item?id=19311487</a>