Limit for Entities in Data store

I am also not sure, but now you have made me curious as well. Let's see if someone reply to this question. 

I am not aware of a limit. How many entities do you plan to add?

Around 50 entities in one Data store in future it could scale higher ....................

Adding to that question - what could be the possible consequences of having many entities in one data store instead of dividing it into many stores? Could that have impact on performance?

All entities in a data store use the same DB connection which has a limited number of open connections. That might or might not be an issue, depending on your environment and applications.

I suggest to talk to your Lead Designer and/or architect to discuss sizing requirements.

My largest Data Stores have between 30-40 Entities.  I haven't run into any technical issues here as far as performance or connection limitations, etc. 

The only 'annoyance' I've had with this setup was somewhere between Appian 22.x and 23.x, there was a change in the default column expectation for boolean CDT values.  Previously, simple CDT configurations such as below would successfully map to bit values in the database (MSSQL):

<xsd:element name="approvalCompleted" nillable="true" type="xsd:boolean" />

In Appian 23.x, these now expected the underlying data configurations to be tinyint instead, preventing the data store from publishing due to a mismatch (legacy configuration still worked in production, but could not be changed until all satisfied new validation).  This required all CDTs mapped to entities containing boolean values to be updated explicitly as below:

      <xsd:element name="approvalCompleted" nillable="true" type="xsd:boolean" >
        <xsd:annotation>
          <xsd:appinfo source="appian.jpa">@Column(name="approvalCompleted", columnDefinition="bit NULL")</xsd:appinfo>
        </xsd:annotation>
      </xsd:element>

Not a big change, but this required updates to all 30 entities before updates to 1 could be published.  If other entities were under separate development cycles, this would become annoying.

Additionally, security can be configured at the Data Store level, grouping together prevents independent security configurations, if necessary.

For these reasons, and potential connection limitations, I recommend splitting into a few Data Stores to keep the entity counts reasonable.