5 ms·

Hey everybody, today we launched FaunaDB Serverless Cloud, 4 years in the making. FaunaDB is a strongly consistent, globally distributed operational database. I

Hey everybody, today we launched FaunaDB Serverless Cloud, 4 years in the making. FaunaDB is a strongly consistent, globally distributed operational database. It’s relational, but not SQL. We're excited to open our doors and explain more of our design decisions. Our team is from Twitter, and that experience has deeply informed our interface and architecture. Try it out and let us know what you think. An on-premises release is coming later this year.

assface 10y ago
> It’s relational, but not SQL. Why not? If you already support relational algebra, it seems like a non-brainer to just add SQL. Even if it's only SQL-92 you would be able to support some existing tools/ORMs almost for free.
- elvinyung 10y ago
  This is explained a bit in a blog post[1]. Basically, this is because FaunaDB uses Calvin to do distributed transactions, which makes it hard to support OLAP-style SQL sessions. (If I understand the Calvin paper[2] correctly, this has to do with a combination of how it doesn't support "dependent" transactions, and how it does concurrency control.) 1: https://fauna.com/blog/distributed-acid-transaction-performance https://fauna.com/blog/distributed-acid-transaction-performa... 2: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf http://cs.yale.edu/homes/thomson/publications/calvin-sigmod1...
  - ergl 10y ago
    Yes, it has to do with the way Calvin handles transactions, which are required to declare their read and write sets before executing. These kind of transactions are also called static, and are normally of the type "I have this read/write operation(s) against multiple keys, go and do it" vs dynamic transactions that might depend on read values from the db to figure out what to do next.
    - jchrisa 10y ago
      We allow you to make different writes depending on reads. The query language has loop and control flow structures, so you can push a lot of the logic to the database. You can read more about the query language here: https://fauna.com/documentation/queries https://fauna.com/documentation/queries
      - ergl 10y ago
        You can issue writes depending on reads, but are they performed in the same transaction? If I do `if(read(A) = 0) then write(B, 1) else write(C, 2)`, would that be executed in 1 or 2 transactions?
        dwenzek 10y ago
        It should be executed in a single transaction. But the query may be scheduled more than once. According to the Calvin paper, there are two strategies here: * Either, the write set of the query is considered to be {B,C}. * Or the query if rewritten and scheduled several times, the `if` operation beeing replaced by an assert operation, until the assertion is indeed true, in which case the transaction proceeds using a smaller write set. If not, the query is scheduled again after having been rewritten to match the current values. In other words, if A equals 0 then the query is rewritten as `assert A == 0 then Write(B,1)`. Otherwise the query is rewritten as `assert A != 0 then Write(C,2)`. Months ago, I implemented a prototype after the Calvin paper and used the first strategy. It may imply more contentions and even lock the whole dataset with queries like `Write(Read(A),a))`. Sadly, such queries are not rare: updating a distributed index is the typical case. What is the approach of FaunaDB ?
        ergl 10y ago
        Ah, yeah, I suspected it could be fixed with your first approach, but the second one also sounds plausible. But if you go with the first option, then you can end up locking the entire database, as you pointed out with `write(read(A), _)`. Wouldn't your second option cause multiple transaction aborts until you find the rewrite that satisfies the assert? And in that case, the scheduler would need to know if the abort was actually caused by a faulty rewrite. It would be interesting to know what Fauna does in these cases. Is your implementation open somewhere?
Veratyr 10y ago
> FaunaDB Serverless Cloud By "Serverless", do you just mean DBaaS? "Serverless" in the context of a database is kinda weird because the data does have to be stored somewhere. This branding doesn't make much sense to me. > It’s relational, but not SQL. Why not SQL? Is there something your query language supports that SQL doesn't?
- jchrisa 10y ago
  In answer to your first question, we have a blog post about the provisioning trap here: https://fauna.com/blog/escape-the-cloud-database-trap-with-serverless https://fauna.com/blog/escape-the-cloud-database-trap-with-s...
  - Veratyr 10y ago
    It still doesn't make much sense to me. > With pay-as-you-go pricing, your database costs nothing when no one is using it. Combine it with a function-as-a-service provider like AWS Lambda or Google Cloud Functions, and your entire cost structure scales dynamically with usage. In provisioning terms, how is FaunaDB different from existing alternatives like Google Cloud Datastore? What makes it "Serverless"? Are you just saying PAYG = "Serverless"?
    - evanweaver 10y ago
      It is similar to datastore, but with full-blown database features like transactions, joins, multi-region replication, temporal history, covering and compound indexes, graph queries, stored procedures, etc., and you can run it on-premises if you want (currently in beta).
      - wsh91 10y ago
        We also have transactions [1], compound indexes [2] and multi-region replication [3]. I'm not sure what defines a "full-blown" database, but that much is true. [1] https://cloud.google.com/datastore/docs/concepts/transactions https://cloud.google.com/datastore/docs/concepts/transaction... [2] https://cloud.google.com/datastore/docs/concepts/indexes https://cloud.google.com/datastore/docs/concepts/indexes [3] https://cloud.google.com/docs/geography-and-regions#multi-regional_resources https://cloud.google.com/docs/geography-and-regions#multi-re...
hoodoof 10y ago
4 years seems a very long time for development. I'd be interested to hear why, and what you would do differently if you were to start from scratch.
- deleted 10y ago
  [deleted]
- the_duke 10y ago
  I don't think 4 years is long at all for developing an advanced, distributed database solution. It is a long time to go without real world use and user feedback, though.
  - evanweaver 10y ago
    The beta has been in production with cloud and on-premises customers for two years.

assface 10y ago

> It’s relational, but not SQL. Why not? If you already support relational algebra, it seems like a non-brainer to just add SQL. Even if it's only SQL-92 you would be able to support some existing tools/ORMs almost for free.

elvinyung 10y ago
This is explained a bit in a blog post[1]. Basically, this is because FaunaDB uses Calvin to do distributed transactions, which makes it hard to support OLAP-style SQL sessions. (If I understand the Calvin paper[2] correctly, this has to do with a combination of how it doesn't support "dependent" transactions, and how it does concurrency control.) 1: https://fauna.com/blog/distributed-acid-transaction-performance https://fauna.com/blog/distributed-acid-transaction-performa... 2: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf http://cs.yale.edu/homes/thomson/publications/calvin-sigmod1...
- ergl 10y ago
  Yes, it has to do with the way Calvin handles transactions, which are required to declare their read and write sets before executing. These kind of transactions are also called static, and are normally of the type "I have this read/write operation(s) against multiple keys, go and do it" vs dynamic transactions that might depend on read values from the db to figure out what to do next.
  - jchrisa 10y ago
    We allow you to make different writes depending on reads. The query language has loop and control flow structures, so you can push a lot of the logic to the database. You can read more about the query language here: https://fauna.com/documentation/queries https://fauna.com/documentation/queries
    - ergl 10y ago
      You can issue writes depending on reads, but are they performed in the same transaction? If I do `if(read(A) = 0) then write(B, 1) else write(C, 2)`, would that be executed in 1 or 2 transactions?
      - dwenzek 10y ago
        It should be executed in a single transaction. But the query may be scheduled more than once. According to the Calvin paper, there are two strategies here: * Either, the write set of the query is considered to be {B,C}. * Or the query if rewritten and scheduled several times, the `if` operation beeing replaced by an assert operation, until the assertion is indeed true, in which case the transaction proceeds using a smaller write set. If not, the query is scheduled again after having been rewritten to match the current values. In other words, if A equals 0 then the query is rewritten as `assert A == 0 then Write(B,1)`. Otherwise the query is rewritten as `assert A != 0 then Write(C,2)`. Months ago, I implemented a prototype after the Calvin paper and used the first strategy. It may imply more contentions and even lock the whole dataset with queries like `Write(Read(A),a))`. Sadly, such queries are not rare: updating a distributed index is the typical case. What is the approach of FaunaDB ?
        ergl 10y ago
        Ah, yeah, I suspected it could be fixed with your first approach, but the second one also sounds plausible. But if you go with the first option, then you can end up locking the entire database, as you pointed out with `write(read(A), _)`. Wouldn't your second option cause multiple transaction aborts until you find the rewrite that satisfies the assert? And in that case, the scheduler would need to know if the abort was actually caused by a faulty rewrite. It would be interesting to know what Fauna does in these cases. Is your implementation open somewhere?

Veratyr 10y ago

> FaunaDB Serverless Cloud By "Serverless", do you just mean DBaaS? "Serverless" in the context of a database is kinda weird because the data does have to be stored somewhere. This branding doesn't make much sense to me. > It’s relational, but not SQL. Why not SQL? Is there something your query language supports that SQL doesn't?

jchrisa 10y ago
In answer to your first question, we have a blog post about the provisioning trap here: https://fauna.com/blog/escape-the-cloud-database-trap-with-serverless https://fauna.com/blog/escape-the-cloud-database-trap-with-s...
- Veratyr 10y ago
  It still doesn't make much sense to me. > With pay-as-you-go pricing, your database costs nothing when no one is using it. Combine it with a function-as-a-service provider like AWS Lambda or Google Cloud Functions, and your entire cost structure scales dynamically with usage. In provisioning terms, how is FaunaDB different from existing alternatives like Google Cloud Datastore? What makes it "Serverless"? Are you just saying PAYG = "Serverless"?
  - evanweaver 10y ago
    It is similar to datastore, but with full-blown database features like transactions, joins, multi-region replication, temporal history, covering and compound indexes, graph queries, stored procedures, etc., and you can run it on-premises if you want (currently in beta).
    - wsh91 10y ago
      We also have transactions [1], compound indexes [2] and multi-region replication [3]. I'm not sure what defines a "full-blown" database, but that much is true. [1] https://cloud.google.com/datastore/docs/concepts/transactions https://cloud.google.com/datastore/docs/concepts/transaction... [2] https://cloud.google.com/datastore/docs/concepts/indexes https://cloud.google.com/datastore/docs/concepts/indexes [3] https://cloud.google.com/docs/geography-and-regions#multi-regional_resources https://cloud.google.com/docs/geography-and-regions#multi-re...

hoodoof 10y ago

4 years seems a very long time for development. I'd be interested to hear why, and what you would do differently if you were to start from scratch.

deleted 10y ago
[deleted]
the_duke 10y ago
I don't think 4 years is long at all for developing an advanced, distributed database solution. It is a long time to go without real world use and user feedback, though.
- evanweaver 10y ago
  The beta has been in production with cloud and on-premises customers for two years.