Question 1

Which Cosmos DB API does Polytomic support?

Accepted Answer

The Core SQL API only, which is the native Cosmos document API and what most applications are built on. Accounts provisioned with the MongoDB, Cassandra, Gremlin, or Table APIs are not supported by this connector, so check which API your account was created with before planning a sync, since it cannot be changed afterwards. Authentication is the standard account URI and key pair from the Azure portal.

Question 2

Does Polytomic support change data capture for Cosmos DB?

Accepted Answer

Yes, through the Cosmos change feed, for models that select a container. Polytomic enumerates the physical partition ranges behind the container, reads each one's feed, and checkpoints them independently using the ETags Cosmos provides, processing many partitions concurrently. Checkpoints survive partition splits, so scaling your container does not force a full reload. This is what makes ongoing ETL into a data warehouse affordable rather than rescanning the container each run. One caveat worth planning for: the change feed does not emit tombstones, so hard deleted documents will not propagate as deletions to your destination. Soft deletes with a status field work well here.

Question 3

Can I use a Cosmos SQL query as the source instead of a whole container?

Accepted Answer

Yes, and cross partition querying is enabled so the query is not restricted to a single partition. This is useful for single container designs where you want to pull out one entity type, or to project a narrower shape before the data leaves Cosmos. The trade off is that SQL query models cannot read incrementally: incremental is explicitly disabled for them and the query is rerun as a full read each time. If a container is large and changes often, selecting the container and using the change feed is usually the better choice.

Question 4

How are nested documents and inconsistent item shapes handled?

Accepted Answer

Nested objects are recursively flattened into selectable paths while the original object field is also retained, so you can map an inner value directly or keep the whole structure. Arrays stay as arrays and are not exploded into rows. For schema inference Polytomic samples up to a hundred documents and unions the fields it finds across them, with the first useful type for a field generally winning. Rare fields outside the sample, or fields whose type varies between documents, may need to be added or corrected manually.

Question 5

Will syncing burn through my provisioned RUs?

Accepted Answer

Reads consume request units like any other Cosmos workload, and there is no user facing RU budget or page size control in the connector, so plan the schedule with your provisioned throughput in mind. Two things help. Change feed reads are far cheaper than repeatedly scanning a container, so enabling them is the single biggest lever for keeping ETL costs down. And if you need to narrow what is read, do it with a Cosmos SQL query rather than Polytomic side field filters, because those filters are applied after the documents are retrieved and therefore do not reduce RU consumption. Polytomic honors the retry after interval Cosmos returns when it throttles.

Azure Cosmos DB

Perfect pairings

Change feed incrementals

Cross partition SQL

Nested document support

Example workflows

What you can sync

From Azure Cosmos DB

To your destinations

How it works

How to set up

Frequently asked questions

Why teams choose Polytomic

No engineering required

Flexible data modeling

Handles scale automatically

Start syncing your data with Azure Cosmos DB in minutes

More integrations beyond Azure Cosmos DB