Cosmos provider has many more limitations than those documented

[dougclutter]

Here are a few Cosmos Provider limitations that should be mentioned on this page:

• EF Core Migrations are not supported by the Cosmos Provider. Since this wasn't specifically mentioned on this page, I tried to use Migrations, and it ended...poorly. The error message returned by the Cosmos Provider when trying to initialize migrations is less than useless. Please save other developers the time and frustration by specifically mentioning this limitation on this page.
• Indexes defined on the DbContext are not created by EnsureDatabaseExists. The containers are created, but the indexes are not.
• Check constraints, et al - I haven't specifically tried these yet, but I'm betting they don't work either. If not, please let us know on this page.

I've spent most of my career working with Oracle/SQL Server databases, so my feedback is tainted by my RDBMS background. Nonetheless, I hope this was helpful.

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: a102d2e4-41d0-4619-a463-3e3862311a01
• Version Independent ID: a80b35f2-09dc-da67-df83-253ca5fd78cb
• Content: Azure Cosmos DB Provider - Limitations - EF Core
• Content Source: entity-framework/core/providers/cosmos/limitations.md
• Product: entity-framework
• Technology: entity-framework-core
• GitHub Login: @AndriySvyryd
• Microsoft Alias: avickers

[roji]

@dougclutter at the end of the day, Cosmos isn't a relational database, and there are many relational features which EF supports which aren't relevant there; in general, it's not a good idea to approach a non-relational document database such as Cosmos, and to treat it the same way as one would a relational database.

I'm not sure it makes sense to enumerate each and every relational feature that doesn't work on Cosmos, though I agree that the limitations page could be improved.

[dougclutter]

@roji - While I agree that document databases are very different animals and should be approached differently, I think it is reasonable to expect that many users reading the Limitations page are new to document databases and need additional guidance. There are also a number of reasons why a new user may assume that a Cosmos database can be treated like an RDBMS:

1. Microsoft has named their primary interface to Cosmos SQL API. Which is IMHO a misguided and misleading label. :)
2. Microsoft provides an EF Core Provider for Cosmos. Given that EF/Core is firmly rooted in the world of RDBMS, a developer familiar with EF/Core might naturally assume Cosmos is SQL-like.

The Provider documentation does mention that a familiarity with document databases and Cosmos especially should be considered a prerequisite to using the Provider. Still, I think the Limitations page should go out of its way to enumerate what is not supported. Perhaps it would help to have a grid of all providers produced by Microsoft (SQL Server, In Memory, SQL Lite, Cosmos, et al) with a list of high-level features (CRUD, Joins, Includes, DB Procs/Funcs, et al). The more information a Developer has, the lower their frustration.