[HN Gopher] AWS Aurora Serverless v2: architecture, features, pr...
___________________________________________________________________
AWS Aurora Serverless v2: architecture, features, pricing,
comparison with Fauna
Author : evanweaver
Score : 49 points
Date : 2021-03-24 18:00 UTC (1 days ago)
(HTM) web link (fauna.com)
(TXT) w3m dump (fauna.com)
| joshstrange wrote:
| 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.
| evanweaver wrote:
| It is primarily an architectural and operational comparison.
| pier25 wrote:
| > _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?
| evanweaver wrote:
| 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.
| musingsole wrote:
| > 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.
| ralusek wrote:
| 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.
| pier25 wrote:
| > 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...
| dragonwriter wrote:
| They admit it's an apples-oranges comparison, so why do it?
|
| I mean, isn't Fauna more directly comparable to Dynamo than
| Aurora?
| TameAntelope wrote:
| Apples and oranges are still fruit.
| tryauuum wrote:
| (off topic) in russian instead of "comparing apples and
| oranges" idiom we have "comparing a warm [object] to a soft
| [one]"
| evanweaver wrote:
| 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-...
| mchusma wrote:
| 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."
| saurik wrote:
| > 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).
| giorgioz wrote:
| 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.
| vadorequest wrote:
| 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...
| giorgioz wrote:
| any idea how to lowercase all those capitalized functions?
| evanweaver wrote:
| 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?
| nicoburns wrote:
| Knex syntax (http://knexjs.org/) is reasonable. It's
| basically method chaining.
| giorgioz wrote:
| 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?
| mwakerman wrote:
| 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)'
| pc86 wrote:
| Capitalized method names are pretty common
| pier25 wrote:
| Indeed. Maybe not in the JS world though.
| pier25 wrote:
| > Maybe that could be changed with: let { Create, Collection} =
| q
|
| Yeah, I do that all the time. It makes FQL code much cleaner.
___________________________________________________________________
(page generated 2021-03-25 23:03 UTC)