> There are many significant differences in capabilities, and design approaches between other systems (CockroachDB and Spanner) and Cosmos DB. At a very high level differences are at two levels - the design of the database engine and the larger distributed system.
> Please note that these papers are significantly behind the current state of the implementation. The most crucial aspect that these papers dont cover is the integration of the database engine with the larger distributed system components of Cosmos DB including the resource governance, partition management, and the implementation of replication protocol / consistency models etc.
> Our goal is to publish all of the design specifications including TLA+ specs over time.
Except DocDB is not a drop-in replacement despite what Amazon says.
People have tried and failed to get our software running on DocumentDB, whereas another developer got it running on CosmosDB with minimal changes upstream.
Not affiliated with MS in any way, just sharing what I've witnessed secondhand.
Sure, but if you restrict yourself to lowest-common-denominator features so you can migrate between Spanner and CosmosDB then you are paying for features you aren't using and are at a competitive disadvantage to those that can leverage them.
For those wondering about it, don't bother searching for 'NewSQL'. It's a buzzword that doesn't actually mean anything other than 'it's not mysql, pgsql, oracle, or mssql.' They claim to improve on the standard DBs, but every single DB does it in a different way. The name is useless.
Instead, read the 'who we are' and 'how it works' bits on NuoDB's page. They were much more informative.
I think it sounds exciting and fresh... And doesn't seem to be open source at all.
I'm not allergic to paying money for software, but I've found I'm happiest when using something that I can guarantee will survive, even if may have to do so by my own hand. Commercial products have a tendency to be a pain in the rear.
It is PaaS , you are locked down (just like a lot of other solutions.) The biggest problem we had with other no-SQL databases (we were high on interop and started with HBase / Phoenix ) is that over time the storage costs and operational costs get out of hand especially if we do not have a good data archival part (sometimes limited by legality as well).
As for your frustrating experience , the mileage varies. We were happy with it , so no comments on that one.
For cosmos , we used it for extremely "hot"/"warm" data that was aggregated and made available readily for applications to use. We had reserved instances (big on Azure) , so we keep things in check that way.
If you just want to compare the database aspects that works. Once you get into other features that gets messier as functionality is split across components in different ways.
For example Prometheus vs InfluxDB is not a great comparison, whereas Prometheus+Alertmanager vs InfluxDB+Kapacitor is.
Hi, I am from Cosmos DB engineering team,
I'm sorry to hear you ran into issues with our .NET SDK. We're constantly updating our SDKs, and welcome feedback on GitHub, please post the issues there and we will get back to you shortly. For the current generally available .NET SDK V2, the GitHub page is at [1].
The upcoming V3 version of Cosmos DB .NET SDK is open sourced at [2], please give it a try when you have a chance / tell us what you think.
[1] https://github.com/Azure/azure-cosmos-dotnet-v2
[2] https://github.com/Azure/azure-cosmos-dotnet-v3
How is this comparable to fathomdb in terms of what it provides on a business level. (not how i.e. fathomdb leverages 'the cloud' where as this seems to be using specialized hardware?)
YugaByte DB product manager here. Yes, CosmosDB and its underlying architecture were indeed not yet publicly available when we started the YugaByte DB project early 2016. However, classifying CosmosDB as a distributed SQL database is a bit of stretch given no support for SQL on the write path (the write path uses a custom document API). This means no support for multi-row/multi-shard ACID transactions as well as features such as client-initiated session transactions.
reply