Are there any performance concerns with an Azure function that has many output bindings?

I have an Azure function that has a CosmosDB change feed trigger that I would like to populate 6 different materialized views. To accomplish this, I added 6 different CosmosDbOutput bindings. Are there any performance concerns with that many output bindings? I can't seem to find any documentation that mentions large amounts of bindings on one function. Do functions even have a limit to the amount of bindings they have? The ingestion table that the azure function is listening to may get tens of thousands of updates per minute, and all these changes need to upsert into all 6 materialized views.

Is there any advantage of using the CosmosAsyncClient in my project instead of using output bindings in the function?

@FunctionName("ingestionToMaterializedViews")
    public void CosmosTriggerAndOutput(
            @CosmosDBTrigger(
                    name = "cfTrigger",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "ingestion",
                    leaseCollectionName = "leases",
                    connectionStringSetting = "",
                    createLeaseCollectionIfNotExists = true) Object inputItem,
            @CosmosDBOutput(
                    name = "a",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameA",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<Item>> outputA,
            @CosmosDBOutput(
                    name = "b",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameB",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<Item>> outputB,
            @CosmosDBOutput(
                    name = "c",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameC",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<Item>> outputC,
            @CosmosDBOutput(
                    name = "d",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameD",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<Item>> outputD,
            @CosmosDBOutput(
                    name = "e",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameE",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<Item>> outputE,
            @CosmosDBOutput(
                    name = "f",
                    databaseName = "%CosmosDBDatabaseName%",
                    collectionName = "testNameF",
                    connectionStringSetting = "%CosmosDBConnectionString%") OutputBinding<List<VinItem>> outputF,
            final ExecutionContext context) {

This is what the signature currently looks like.

The Output binding will keep a Singleton instance of the client for each different connectionStringSetting, if all these are using the same connectionStringSetting, then it should be fine because they would all reuse the same client underneath.

If the question is, do I need that many collections, that depends on your use case though.

But from the performance perspective, there is nothing wrong, you still get the Singleton.

Be advised though, if you are configuring the Extension on Direct Connectivity mode, that each collection represents different Partitions, with different Connections, so the volume of Connections established will be a factor of the number of collections (there is no way to avoid that).