To me it seemed vaguely interesting but a little bit overpriced for real-world usage outside of fortune 500s or big government, where budgets aren't always a concern.
For comparison, I had the same eventhub feed Kafka Connect to dump it into Mongo 5.0's new timestream collections on a $200/month VM, and after running both outputs at full volume for a couple days, Azure offered me a helpful suggestion to downsize the under-utilized VM and save money.
I haven't quite figured out if the RU rate is just too high to be economical, and counts on large orgs with large data to expect a large bill; or if the RU model simple works badly for high velocity data. I've verified that the pricing model now scales down properly for small/medium loads, at which point the various high availability/geographcial distribution features really add value. I'm trying to conceptualize how the RU cost, amortized across longer term storage and less demanding ingress/egress schedules, can work out. For our scenario, Cosmos functionally offers exactly the horizontal scalability we need.
As a different sanity check, I set up a SQL Server account as the ingestion database and saw comparable costs, so it wasn't that Cosmos itself has an unworkable pricing model.
I've recently tested it as needed geospartial query support for a hobby project and the cost is cents per month with the serverless pricing model. I'm also accessing CosmosDB outside of Azure to use low cost VPS hosting and latency is pretty acceptable for web type stuff.
If you are DB read/write heavy obviously pricing is going to be higher due to pay for what you use, pre-provisioned pricing will become the better value option at that point.
I couldn't justify it prior to the serverless introduction; but I'm doing 1m+ ops/mo now for <1usd for some high-concurrency state tracking ops.
It has a MongoDB API Layer and a Cassandra API Layer (as well as SQL which is preferred).
Works just fine, apparently cost can blow out though with high usage, I haven't got there yet.
Does have a free tier.
The former, lift and shift scenario I can understand as you need to structure your data to work best with CosmosDB/DynamoDB etc. If it's the latter that is useful to know as I'm currently building a POC on Azure so I should watch out for it.
This was all part of a benchmarking exercise to figure out how to scale an app with minimal changes so we expected some performance penalty, just not as steep as what we observed.
However, CosmosDB is a managed service, easier than setting up your own database. Did you exclude Atlas from your conclusion for some reason? Ie did AKS do things that Atlas could not?
You must be diligent to develop your application to use it efficiently from both a cost and performance/latency perspective.
Those that put in the work may not love it, but they are very successful at operating at scale. Massive, insane scale.
We use it with a private endpoint and turn off public access. I've been generally happy with it.
As long you have a good partitioning strategy seems work without much effort put into it.