10 ms·
Show HN: FaunaDB, a strongly consistent, globally distributed cloud database
- evanweaver 10y agoHey 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 agoThis 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 agoYes, 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 agoWe 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 agoYou 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 agoIt 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 agoAh, 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 agoIn 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 agoIt 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 agoIt 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 agoWe 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 ago4 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 agoI 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 agoThe beta has been in production with cloud and on-premises customers for two years.
- nunzi 10y agocan't wait to learn more
- evanweaver 10y agoThe docs are now public...so you can. We have a blog post by Daniel Abadi coming as well about the consistency model.
- btilly 10y agoHave you talked to Aphyr yet about testing it and having it become an entry in https://aphyr.com/tags/jepsen https://aphyr.com/tags/jepsen? I've learned to not believe that distributed software will work in practice in the way that its authors claim it will. The stronger the claims, the more important it is to have an independent test validating it before I even think of trusting it.
- evanweaver 10y agoTotally understandable. We have been talking to Kyle. We have internal verification systems and will be publishing more later this year to that effect. For what it's worth, we have built high-performance distributed systems before....so it's not just wishful thinking.
- jchrisa 10y agoThere is a related technical blog post [1] and discussion [2]. Also I've got a companion blog post on the Serverless.com blog at [3] [1] https://fauna.com/blog/escape-the-cloud-database-trap-with-serverless https://fauna.com/blog/escape-the-cloud-database-trap-with-s... [2] https://news.ycombinator.com/item?id=13877223 https://news.ycombinator.com/item?id=13877223 [3] https://serverless.com/blog/faunadb-serverless-authentication/ https://serverless.com/blog/faunadb-serverless-authenticatio...
- zenithm 10y agoWhat's the biggest deployment so far?
- jchrisa 10y agoWe have a bunch of customers listed in the press release. [0] Our managed cloud installation is about the size of our large customers. NVIDIA launched their latest world-scale user facing service on top of FaunaDB. Personally I'm more interested in helping people writing fresh apps use FaunaDB, because while we can solve enterprise problems at scale, it's the greenfield apps that will be able to best use our advanced features. [0] http://finance.yahoo.com/news/fauna-launches-faunadb-serverless-cloud-131200188.html http://finance.yahoo.com/news/fauna-launches-faunadb-serverl...
- jimreedia 10y agoCool. My team has been looking for something like this.
- jchrisa 10y agoYou can jump directly into the developer dashboard with only an email address here, and start playing with queries: https://fauna.com/serverless-cloud-sign-up https://fauna.com/serverless-cloud-sign-up
- jimreedia 10y agoMy team wants to understand this in context of other databases. Are there any architecture docs available?
- evanweaver 10y agoWe have a white paper coming soon...if you email us at priority@fauna.com we can give you a preview.
- sushisource 10y agoSo... where does the data go? Maybe a simpleton question but I couldn't easily find an answer in the about section. If it's all function-based, where does the data actually get persisted?
- jchrisa 10y agoThis is a database FOR serverless style applications. It runs on servers like most databases, it's not made out of lambdas. But it's built so you don't have to worry about the details. When a traffic spike hits your app we'll keep up. And when your app is quiet, you don't pay for unused capacity.
- sushisource 10y agoOoooooooooh, that makes sense now. I thought it was a database implemented as as whole series of individual lambdas and I was having a hard time figuring out how you guys pulled that one off. Data stored "on the wire"? :D
- inopinatus 10y agoPretty sure this is how reality works: all matter is information, all information is functional, hence all perception is the lazy evaluation of a functional universe. It merely remains to turn this into a startup.
- WorldMaker 10y agoCould be done with data stored in files in S3 buckets. Probably not the most efficient way to run a queryable database, but possibly not the worst either.
- icebraining 10y agoData stored "on the wire"? :D pingfs - Stores your data in ICMP ping packets https://github.com/yarrick/pingfs https://github.com/yarrick/pingfs https://news.ycombinator.com/item?id=9844725 https://news.ycombinator.com/item?id=9844725 There should be a Rule 34 for insane software ideas :)
- wsh91 10y ago(Disclosure: I work on Google's Cloud Datastore.) This looks super neat, and I can't wait to learn more about it, but just for the record: I'm pretty sure this isn't the first serverless cloud database. Both Firebase's Realtime Database and Cloud Datastore (which powers Snapchat and Pokemon Go) are serverless; you pay only for your ops and storage. They've been publicly available for several years.
- evanweaver 10y agoFair enough; I think it depends where you draw the line between key/value store and database. Both of those depend on other distributed storage systems under the hood, as far as I am aware? Or is Datastore an end to end system? I know Firebase was backed by MongoDB.
- elvinyung 10y agoIf I remember correctly, Datastore is basically a thin layer on top of Megastore[1] (aka the precursor to Spanner). 1: https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36971.pdf https://static.googleusercontent.com/media/research.google.c...
- itcmcgrath 10y agoIt's a lot more than a thin layer, but like most systems at Google is a specialized layer that utilizes built on top of more fundamental building blocks that are designed and proven to do a particular job really well. In this case Megastore provides the underly multi-region/datacenter K-V replication services. All the database features like secondary & composite indexes, query language, multi-tenancy support, PAYG model, etc, etc, are built in the Cloud Datastore layer.
- elvinyung 10y ago> secondary & composite indexes Interesting, so you don't use Megastore's indexes?
- jazoom 10y ago$0.01 per simple operation sounds very expensive to me. This would add up very quickly. Edit: I misread it. Perhaps instead of inventing your own point system that you have to explain and hope silly people (like me) don't mix up you could take a lesson from Google Cloud and just lay out the pricing in a table. If you ever add another service you'll have to integrate it also into your made up points system.
- evanweaver 10y agoIt's $0.01 per thousand, not each.
- jazoom 10y agoYou're right. I realised that and came to correct it. Thanks for pointing it out.
- z3t4 10y agoYou should explain how it works. It's not like I'm going to steal your ideas and spend five years implementing them ... or maybe I will if it's good ;)
- jchrisa 10y agoThe node that receives the query figures out which nodes it needs to talk to for an answer, and then it adds the operations to the next batch for those nodes. The batch dispatches, the nodes do their work, the batch commits, and the client receives the response. It's not really a full answer, but maybe hints at the architecture.
- ccleve 10y agoYou might consider removing the badge on the home page that says "Global Latency 2.8 ms". Unless you really can give me latency across the globe of 2.8 ms, in which case your solution to the speed-of-light problem is quite impressive :)
- evanweaver 10y agoReads do not require global coordination because of the way the transaction log advances within each datacenter, but I take your point.
- jazoom 10y agoI'm not sure if you did take the point intended. You would need a datacentre in every city in the world to get that "global latency".
- evanweaver 10y agoSupporting every region in every public cloud infrastructure provider is absolutely the goal. But we can change the little widget to be less confusing, too.
- jazoom 10y agoI find this interesting. Do you plan to have every database record replicated across every one of your datacentres? That would be some crazy high availability.
- jchrisa 10y agoYes that is the model. Each region has a full copy of the data and has its own internal replication factor. The customer can select which cloud regions and providers to replicate to, and pay accordingly. So you will be able to choose how many replicas and where they are.
- pbgiese 10y agoThis sounds a lot like google spanner. I'm no expert though. What's the difference?
- jchrisa 10y agoThe big difference is that we use a logical clock and batches of operations so that we aren't dependent on atomic clocks. We also have a different API style, and plan to run on all the major cloud providers. You'll be able to do consistent operations visible to application code running in different providers.
- snackai 10y agoServerless Database, Global Latency 2.8 ms, Relational but no SQL (whatever sense that makes) BULLSHIT BINGO at its very best.
- hoodoof 10y agoYou could put this more nicely - they have spent alot of time working on it. I'm sure no-one intends "BULLSHIT". One way to handle it when something strikes you as not correct is to politely ask for clarification.
- snackai 10y agoWell no. A Global latency of 2.8 ms is just bullshit. As others pointed out, they did not beat the speed of light. I hate stuff like this. If you really have a worthy product just point out what it really can do, not what in a lab environment worked once.
- btilly 10y agoI agree with the buzzword bingo complaint, but they really do have a claim that is defensible here. Their claim is that you can run an application distributed in a cloud around the world with data in their database, and read queries to their database will get results in an average of 2.8 ms. This puts a lot of caveats on that 2.8 ms claim, and makes it something that is both good and believable. Which makes the claim very much not bullshit.
- realPubkey 10y agoSnackai is right. Bullshit stays bullshit.
- elvinyung 10y agoI'm curious about the relational-ness of FaunaDB. e.g. How do you efficiently maintain integrity of foreign key constraints across the entire system? How fast and consistent are secondary indexes?
- mring33621 10y agoIf my calculations are correct, that's about $87+ million USD to store 1 PB of data for one year?
- evanweaver 10y agoThat doesn't seem right. Will investigate.
- the_duke 10y ago1 [mb hour] * 24 [hours] * 365 [days] * 10^9 [mb] / 1000 [points] * 0.01 [$] = 87.6 million So unless you have some quantity discounts, that would seem to be the price for storing 1 PB , without any querying.
- evanweaver 10y agoYeah it's our mistake. It's actually gigabyte-hour.
- ryanworl 10y agoSo in the OP's example, the cost is $87,000 per petabyte-year of storage? EDIT: I see mentioned in another post this a per-replica cost. So it would be roughly $87,000 times the number of replicas, ignoring the initial queries that inserted the data in the first place?
- evanweaver 10y agoI think so but we are going to run the cost regressions again and make sure it's in line with market.
- neuronsguy 10y agoYes that's what I worked out as well. That's not doing any operations just storage.
- Efrim-Lipkin 10y agoHi guys. Can I ask a simple question? I understand that we are talking about a globally distributed, serverless and yet consistent relational database. My question is about latency. How long does it take for transactional atomicity to become a consistent read on a globally distributed database? (1) And what are the measures taken between entry nodes to prevent clients from recieving inconsistent data? (2) As I ponder this, I am struck by not the consistency problem, as that is solvable. But I am struck by the latency problem of assuring that all global queries are consistent for some (any) time quanta. What sort of latency should be expected? both questions (1) and (2) are interesting, but (1) is critical while (2) is academic. Thanks, and very interesting work guys. EL
- elvinyung 10y agoLooks like FaunaDB uses Raft[1], so I'd expect that data is sharded into multiple consensus groups, like Spanner or Megastore. That would mean consistency on a single shard/consensus group is basically just dependent on reading from and writing to the Raft leader. 1: https://news.ycombinator.com/item?id=13645876 https://news.ycombinator.com/item?id=13645876
- freels 10y agoFaunaDB has a per-database replicated transaction log. Once a transaction has been globally committed to the log, it is applied to each local partition that covers part of the transaction. By this point, the transaction's order with respect to others in a database and results are determined. While writes require global coordination to commit, reads across partitions are coordinated via a snapshot time per query, which guarantees correctness. In short, writes require a global round-trip through the transaction pipeline; reads are local and low latency.
- Efrim-Lipkin 10y agoThis is a very good answer. So if I understand you correctly (please correct if I do not), atomicity is handled on a per connection basis (writes cannot be distrubted). And there may be high latency in distributing a transaction, but read consistency is guaranteed by timestamp (equivalent to versioning). Is this correct? EL
- dsl 10y agoHow are you running this serverless? Is it a thin application in front of AWS or Google BigQuery?
- jchrisa 10y agoNo, this is not made OF serverless, it's made FOR serverless. We run on big nodes in the same cloud as your app.
- marknadal 10y agoIf your database is not Open Source then your marketing lingo needs to be more open or else you'll have the same mistake as FoundationDB (which looked like vapor-ware). As a proprietary service, you are now competing against Cloud Spanner which (while people love the underdog) means your toast because they have Eric Brewer to hand wave away their marketing lingo. On the flip side, you are competing against Cockroach, but they are Open Source so that puts you in a rock and a hard place. From previous comments of mine, you may know I don't think Cockroach has much of a future either because Globally Consistent databases aren't going to cater to the necessary P2P future of the web (5B+ new people coming online, 100B+ IoT devices, graph enabled social web, Machine Learning, etc. which is what we, http://gun.js.org/ http://gun.js.org/ , caters to and we just successfully ran load tests on low end hardware doing 1.7K table inserts/sec across a federated system, we plan on getting this up to 10K inserts/second on cheap [if not free] hardware). Why are these systems going to fail to pick up the market? Because the best of the best, both in engineering and as an Open Source community, RethinkDB (which I praise highly) couldn't. At the end of the day, the few companies that need globally consistent transactions will trust (for better or for worse) Cloud Spanner, and the others who want to roll their own infrastructure will try Cockroach but ultimately switch to RethinkDB in the end. So on that note, as others have noted, don't use your /fantastic/ marketing opportunities (top of HN) to make false claims about being "industry first", it won't help you gather a developer community. Use this time to win developers over like Firebase did (which itself now has their community scared of when/if Google will shut them down, those developers are now flooding to RethinkDB and ours, despite Firebase being one of the best - high praise for them as well, like Rethink).
- elvinyung 10y ago> Globally Consistent databases aren't going to cater to the necessary P2P future of the web Well, that's an interesting assertion. Why do you think that?
- marknadal 10y agoBecause even a "3ms latency" (which was a problem, with respect to "global", that other people have commented out) can absolutely kill the performance for IoT data that may be emitting thousands of updates a second. Those systems are largely highly localized, and so /strong eventual consistency/ is more important than globally consistent blocking operations. Also, again with 5B+ people coming online, Master-Slave systems (even distributed ones) still have a huge bottleneck already in the present day. P2P systems (master-master) will scale better in these settings.
- deleted 10y ago[deleted]
- doublerebel 10y agoThat pricing model and serverless model is why I've always chosen CouchDB/Cloudant. If I'm doing the MB/hour to GB/month conversion correctly, Fauna cloud is significantly cheaper. I see Fauna has temporal queries, but receiving events is strictly pull, there is no push or single feed?
- jchrisa 10y agoEvent push / feeds are on the roadmap. Currently we have everything implemented at the data model level to do live query feeds, you just have to do polling until we ship the feature. I'm working on a follow up example to this CRUD one, that implements a multi-user TodoMVC, and will use event queries to keep the UI updated between tabs and users. You can see the basic Serverless CRUD starter example here: https://fauna.com/blog/serverless-cloud-database https://fauna.com/blog/serverless-cloud-database
- gregwebs 10y agoI think Fauna is not very good at docs and communication yet, at least judging by confusion from some of the comments and by reading their docs. But launching will probably make them a lot better at it. Here are my notes which may add clarity for some: similar to a RethinkDB/MongoDB: * Designed to be great for storing application data. Fields can be dynamically added (schemaless) and their values can be arrays so it is easy to maintain data locality according to your application use patterns. * Uses a non-SQL query language * Probably not great for ad-hoc reporting (arguably SQL is a requirement for that) Unlike MongoDB: supports joins Unlike RethinkDB: great support for transactions, just not SQL transactions with an open session (which are unnecessary for an application) Unlike most databases * cloud-hosted and pay-for-use (on-premise is on their roadmap) * claims support for graph data by storing arrays of references * QoS built-in so you could run a slow analytics query without disrupting your application Cons * Unfortunately just like MongoDB/RethinkDB they have no real database-level integrity of schema and foreign keys, but at least foreign keys are on their roadmap. I am a huge fan of the cloud-hosted pay for use aspect: I wonder why anyone would design a DB today without this in mind. You can transfer your data from a pay-for-use application DB (FaunaDB or Google DataStore) to a data warehouse (Snowflake or Google BigQuery) which is also pay for use and gives you SQL reporting abilities.
- freels 10y agoThanks, we realize the docs still have a long ways to go and are working to improve them as fast as we can. This is a good summary. We're definitely aware that the lack schema definition is a problem for certain use-cases, and solving this is on our roadmap.
- danthemanvsqz 10y agoI think they missed Google's launch of Spanner their distributed strongly consistent DB.
- evanweaver 10y agoSpanner is great, but it's not pay as you go, or multi-region (yet), or multi-cloud.
- akerl_ 10y agoIt seems like one of the big issues with the marketing copy here is some of the word tricks being played: Any first-read of "The first serverless database" has the implication that the database is serverless. Comments from FaunaDB folks in this comment page clearly indicate that they mean is that it's the first database for serverless, which is a pretty bold claim, given Google and AWS and any number of other providers offer databases that are accessible from serverless things, so it essentially boils down to "The first database that's marketed specifically to serverless use cases", which is maybe true but also kindof not a useful trophy to put on the mantle? This is further muddled by the blog post linked to from the launch announcement (https://fauna.com/blog/escape-the-cloud-database-trap-with-serverless https://fauna.com/blog/escape-the-cloud-database-trap-with-s...), which includes "FaunaDB Serverless Cloud is an adaptive, serverless database". Nobody is reading that and thinking "ah, an adaptive database for serverless apps". To describe it as "The first active-active multi-cloud database", is possibly true if you mean "the first time a single company has sold a publicly-available database-as-a-service running on multiple cloud providers". But the text says "database" where "public database-as-a-service" would be the accurate term, leaving the reader with the impression that no existing databases can be set up on multiple cloud providers in an active-active HA config, which is absurd. Fixing the copy here should be pretty easy, and they're already headed in the right direction with the next bullet point, although it as well refers to "database" where it means "database-as-a-service". It feels like somebody on marketing really wanted to have a list of firsts, so they toyed with definitions of words until they thought they could flex these into being technically accurate. I get the same feel from the closing argument in the linked blog post: "The query language, data model (including graphs and change feeds), security features, strong consistency, scalability and performance are best in class. There is no downside.". I don't think I want to trust a database if the folks designing it couldn't think of any downsides.
- evanweaver 10y agoUnderstand. We can be careful to be more accurate even in less technical contexts in the future. Serverless is supposed to mean: a database with serverless pricing, for serverless applications. There's always a tension, too, between "does a feature exist somewhere" and "is it actually usable?". For example, you could perhaps run MySQL Cluster across multiple public clouds...but would you want to? It's surprisingly hard to design for true cross-continent global replication, and the additional latency of crossing public clouds makes it even worse. We've tried to design the best database. We can put in some bugs for you to give it some downsides.
- anamoulous 10y agoI have been a fan of Evan going way back to the early Rails days. Congrats on the launch.
- mdasen 10y agoI feel like I need to note the pricing. $0.01 per 1,000 queries. That doesn't sound like much, but it adds up. Let's say you make 1,000/sec. $0.01 * 60 seconds in a minute * 60 minutes in an hour * 24 hours in a day * 30 days in a month = $25,920. Is that a lot? I think it is. Google Cloud Spanner costs $0.90/hour per node or around $650/mo. Each Cloud Spanner node can do around 10,000 queries per second[1]. So, $650 to Google gets you 10x the queries that $25,920 to Fauna gets you. I mean, for $25,920, you could get a Spanner cluster with 40 servers. Each of those servers would only have to handle 25 queries per second to get you 1,000 queries per second. I'm sure that people are going to question whether FaunaDB can actually do what it claims. At this pricing, I can't imagine someone actually seeing if they can live up to their claims. They have a graph showing linear scaling to 2M reads per second. Based on their pricing, that would be $630M per year. For comparison, Snapchat committed to spending $400M per year on Google Cloud and another $100M on AWS (and people thought the spend was outrageous even for a company valued at tens of billions of dollars). This is more money for the database alone. Heck, it looks like one can get 5-20k queries per second out of Google's Cloud SQL MySQL on a highmem-16 costing $1k/mo[2]. That would cost $130k-$500k on FaunaDB. It seems like the pricing of FaunaDB is off by a couple orders of magnitude. Ultimately, Spanner is something built by people that published a notable research paper and used by Google. Reading the paper, you can understand how Spanner works and be saddened that you don't have TrueTime servers powered by GPS and atomic clocks. FaunaDB has some marketing speak about how I'll never have to worry about things ever again - without telling me how it will achieve that. It's also implemented in Scala. This isn't a dig on Scala or the JVM, but I use three datastores on the JVM and only one isn't sad for it is Kafka. But Kafka does very little in the JVM - it basically just leans on sendfile to handle stuff which means you don't get bad GC cycles or lots of allocations and copying. FaunaDB is a datastore without much information other than "it's great for everything and scales perfectly". Well, at their pricing, they might be able to make it happen. I mean, most customers would simply move to something cheaper as they got beyond small amounts of traffic due to the pricing. 60,000 queries per second? That'll be $18M per year from FaunaDB or $50k per year from Google. It's not even in the same ballpark. If you really need to scale to 2M reads per second, $630M seems like a lot more than $1.6M for Spanner. Maybe it's an easy way to get some money off people that "need a web scale database", but are actually going to be serving like 10 queries per second and are willing to spend $260/mo to serve that. If they hit it big, it shouldn't be insane to scale it to 10,000 queries per second and milk $260k out of them each month for a workload that can be handled by a single machine. That money also pays for decent ops people to run a big box and consult with the customer if they're going towards 100k queries per second with a $2.6M monthly payment. EDIT: looking over Fauna's blog and some of their comments here, they seem to understand more than their marketing lets on. Daniel Abadi is one of those people whose name carries weight in the databases world (having been involved with C-Store/Vertica, H-Store/VoltDB, and others). While I haven't read the Calvin paper, it looks like a good read. I can see that they are using logical clocks and I can't find it right now, but I thought I saw that they're not allowing one to keep transaction sessions checked out - that all the operations must be specified. So, it seems like there's some decent stuff in there that's currently being obscured by marketing-speak. Still, the pricing seems really curious. [1] https://cloud.google.com/spanner/docs/instance-configuration https://cloud.google.com/spanner/docs/instance-configuration [2] https://www.pythian.com/blog/benchmarking-google-cloud-sql-instances/ https://www.pythian.com/blog/benchmarking-google-cloud-sql-i...
- hubert123 10y agoDo you support a hard limit on money spent? I would like to be able to say 30 bucks a month max or something
- deleted 10y ago[deleted]