Gyxi Promotes Best Practices

With Cosmos DB it is possible put literally millions of document in the same partition and then query them by any property. The performance is acceptable, but the RU usage is horrendous.

You cannot do this with Gyxi. If you have millions of items in the same partition, you literally have to fetch all of them to find the ones you are looking for if you want to query by an unknown property.

With Gyxi you HAVE to make a View based on the properties that you intend to query based on. Then you can efficiently query that data and Gyxi stays fast no matter how you query it.

Which Approach is Better?

Well, it turns out, Gyxi and Cosmos DB have the same approach and that is no coincidence because it is the approach of document databases.

Cosmos DB also encourages database designers to make something similar to “Views”. In Cosmos DB, each container has another partition key definition and it is possible to stream data from one container to another, effectively accomplishing the same as a View in Gyxi.

If you make a View (or a Container) in Gyxi or Cosmos DB then you’re doing it right in the world of document databases. With document databases, your data should already be where you want it to be. You should not be querying large pools of data.

The difference is that in Gyxi you HAVE to structure your data well. In Cosmos DB you can do it wrong and get away with it anyway. It’s an impressive feature and flexibility of Cosmos DB, but invisibly the cost goes way up because of things like this.

Isn’t it better to make the partitioning the right way instead of doing it wrong and never noticing it?