A friend of mine has started a new job, and the company is using event sourcing.
So i asked which Event Store they were using. He said its called Cosmos Db.
Had a quick google, and not too sure what this is.
Is this an Event Store (like our EventStore?)
Does it have any advantages over EventStore?
Steven
CosmosDB is one of the Azure hosted services (and as far as I’m aware right now is tied to Azure).
It has a quite different model to Event Store, and while it’s possible to use it for event sourcing, it is not optimal for it. I know others subscribed to this list have experience using it, so I’ll leave it to them to comment on any differences or similarities.
James
James has summed it up pretty succinctly.
CosmosDb is Azure’s cloud-hosted multi-model database (e.g. it has a graph frontend and a mongodb compatible frontend too for instance) with powerful indexing, querying and cross-geography features. One thing it has a reputation for is being expensive - there’s a grain of truth to that; while not devious, it certainly has many layers of nuance and can absolutely, yield bad results (bills and performance) when used inappropriately.
It absolutely has powerful features that EventStore doesn’t have. That’s also true of SQL Databases (including SQLite) and MongoDb. There are libraries that claim to be Event Store in CosmosDb. There are definitely people using it as an Event Store and/or for Event Sourcing for various kinds of systems, so I would definitely not call your friend a liar.
Being a powerful multimodel database, it has a changefeed and some building blocks that can be used to achieve ends that overlap with those of an Event Store.
But it’s pretty inaccurate to call it an Event Store.
Trying to treat CosmosDb as an Event Store without investing a lot of time in understanding (and, critically, measuring) the charging model is a pretty bad idea (i.e. big bills, hard to scale as advertised) for any system with any interesting scale.
–Ruben
Just to add to that, Cosmos does have something called the document change feed, which essentially allows you to have triggers to other compute e.g azure functions. One can use that similar to ES to build and rebuild readmodels (it does allow you to retrigger). Costing has also been improved to a bit, but yes it can get expensive fast.