evanweaver

As others have pointed out, measuring latency from an AWS Lambda function to a co-located single node in-memory non-durable key-value database (Redis), or to a co-located single AZ eventually consistent key-value database (DynamoDB), doesn't have anything to do with measuring client-observed latency from the browser to a globally distributed ACID-compliant document database.

A similar process co-located with a Fauna region normally can also perform simple reads in small numbers of milliseconds.

Similarly, a browser client querying a lambda function multiple times from the other side of the world will also be quite slow, even if the lambda "thinks" its queries are fast because its database is right next to it.

It is not completely clear to me what else is going wrong, but the basic premise of the benchmark is invalid, and there are other errors in regard to Fauna. For example, index serializability only affects write throughput; it has nothing to do with read latency. The status page reports write latency, not read latency, etc.

For a more even-handed comparison of Fauna to DynamoDB, see this blog post: https://fauna.com/blog/comparing-fauna-and-dynamodb-pricing-...

Dynamo strongly consistent transactions are still limited to a single region, and are eventually consistent outside of that region. For example, in Dynamo, it is not possible to enforce uniqueness via multi-region strongly consistent transactions. Fauna can do this.

The Dynamo transactions do increase latency, but not to the same degree as Fauna. However, they are not achieving the same level of transactional correctness either, or really any correctness at all in a multi-region context.

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-...

It is primarily an architectural and operational comparison.

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 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.

We are in agreement, the difference in experience as you move between denormalized key/value style modeling and normalized relational modeling is the core of the post. DynamoDB has added relational-like features, but using them in a traditional relational way goes against its architectural grain.

Is it necessary that data modeling flexibility must decline as an application matures and scales, though? This was one of the larger millstones around our neck at Twitter and what we are building Fauna to avoid.

You can get a physical HDMI button so you don't even have to unplug anything: https://www.amazon.com/gp/product/B01L8LLP2G/

Congrats Guillermo and team!

What you describe is read uncommitted. From your own docs:

> A third party that performs cross-database reads can observe partial commits while a 2PC transaction is in progress.

Regardless of rollback status, the in-flight transaction will not be observed correctly across shards, for example, with a cross-shard join. It doesn't matter what the consistency guarantee within a shard is; this is not ACID nor is it serializable.

What situation? Are cross-shard transactions ever isolated?

> There are in fact distributed transactions, and cross shard joins. You can in fact do full cross shard ACID transactions.

The Vitess docs explicitly say that 2PC transactions are not isolated and are not ACID.

Did something change?

Private/restricted social networks do not work as businesses. They are antagonistic to both viral growth and hit content.

Many, many have tried.

There have been talks at GDC and elsewhere about this...my memory is that humans don’t like being surprised by a smart AI that silently builds up resources and suddenly and mercilessly betrays and annihilates them, which is the obvious winning strategy. Humans don’t even like the random battle results to be truly random but expect them to hew very closely to the outcome of the odds as presented. The AI is grindy and unsophisticated on purpose.

Did they patch out the way supply crawlers completely break the end game? How do you get started simply with these mods?

Never had any problems with Da Bird wand.

https://www.dabird.com/da-bird

The SQL support? Yes, even that.

See @freels’ reply above.

I think it is fair to say that the Calvin paper is visibly incomplete and expresses some constraints in a way that makes them seem insurmountable when they are not; specifically, they are only constraints within the log, but do not constrain the database experience overall.

Applying Calvin to traditional RDBMS workloads was a very unlikely creative exercise because it required questioning these explicit constraints.

The Spanner paper also leaves a lot unexplained, but it is less obvious until you are too far down the path to turn back. After all, it worked for Google. Calvin did not have that real-world proof. Combine that with the pessimism of the paper itself and nobody was willing to pick it up.

Nobody in industry understood how to apply Calvin until we did at Fauna. That is the only reason; the rest is engineering path dependence.

> Are you certain a MySQL SLA-level support contract would have solved their scalability issues?

This pitch may have been mentioned in passing to me but I don't remember. From the perspective of I and many others who ultimately solved the scalability issues, the MySQL boat was simultaneously sinking and on fire, while nobody knew who the captain was supposed to be. An insurance policy that promised that somebody with a badge would dedicate 8 hours a month to buffing out scratches was not useful.

It was less "it's OSS, we don't need to pay" and more "only God can help us now".

I remember Irix as the bad one. SunOS/Solaris was ok. Linux/BSD was worse, until it was better.

It's absolutely an issue when multiple applications or users write to the same data from different locations, or when users move around.

If the application only lives in one place you are paying for the latency to reach the application from the remote client in the first place, even if the latency from the app to the database is "fast".

FaunaDB gives you local-latency reads and minimum global write latency from everywhere.

We will look into this...seems like a CDN issue.

Thank you! Streaming is coming.

Optional write-time validations are on the roadmap. FaunaDB does enforce unique constraints via indexes already.

FaunaDB is temporal as well and people don't really enjoy migrating the past, so it has to be a little different than a traditional RDBMS schema. But ultimately it will be more flexible as well.

It's the write transaction latency from that region. Fauna is a global database and data always commits to multiple global regions for durability.

As you can see, the write latency is pretty consistent regardless of source region, unlike databases like Mongo that are homed in a single location and fast from nearby but slower and slower the farther away the client application is.

Yes we do! :-)

Go go 8base team! I met them at GraphQL Berlin and was really impressed by their product. Fills an important hole in the JAMstack ecosystem.

You mean the joint venture between Microsoft and Sybase that led to SQL Server? This was legal, soup to nuts.

Oh man, I played Popcorn on our 386sx with grayscale screen. Haven't thought of that game in almost 30 years.