I fully agree with this idea, it doesn't make sense to me that 1 AO for a static entity with maybe a handful of records cost as much cloud resources as a entity with potential millions of records.

Its even worse if the static entity is in a library as it has even more limited usage. One AO costs 33,33€/y (5000€/150). I think it's a lot for something that is mostly an enumeration. 

I agree, charging for Static entities makes them no longer usable in regular projects. Outsystems should find a way to improve this to avoid affecting developers' definitions of static entities in the future. 

100% Agree!

I have been considering a project to consolidate our static entities into a shared standard table in order to reduce AOs.  It seems silly to burn Dev team hours on this when the end result means being unable to leverage a core OutSystems feature/Development accelerator.

100% Agree! 

100% Agree! 

Outsystems teams, Empathetic listening please.

I completely agree. This poses significant challenges for the design process. I think it would be more suitable if 1 AOs = 5 static entities. 

I Agree, Counting 1 AO for Static entities doesn't make sense since these entities will only be used for enumeration and conditions. 

I Agree.

Totally Agreed!
It's a lot to charge.

Agreed, @Kiet Phan  Thanks for bringing this up.

100% agree. 

Avoiding using statics will lead to lower performance. Which ultimately damages the platform's image as an effective solution.

I agree.
For saving AO count we are using hard coded values and one of project we marge all static entity on one. It will be very complex to handle while development.
OutSystems need to find a way to remove consider Static Entity as AO.

@Kiet Phan this is an excellent idea ;) 

Agreed,

Static Entities should not be count as AO.

True, our static entities rarely contain many records, and there are no write operations for them either 

It makes perfect sense—in real-time applications, we frequently don't use static things. 

Well thought out!  This makes sense. I agree with this.

Yes, I agree with this

I agree since we don't frequently update the static entity. 

Totally agree!

Totally Agreed!

Best approach will surely be to exclude static entity from licensing.

But if that's not possible, Outsystems should work and bring something new to address the Enum kind of usage of static entities.

I completely agree.
In my projects, we started replacing Static Entities not because it made the solution better, but purely to avoid AO usage. It's ironic that something meant to simplify development ends up being avoided. 

This workaround increases complexity and maintenance effort just to stay within AO limits. If OutSystems can provide some flexibility, like excluding small static tables or grouping them under one AO, it would really support cleaner, scalable app design without penalizing developers. 

That makes perfect sense— in real-time applications, we often avoid using static elements.4o

Agreed!

We also faced this AO count problem due to the creation of many static entities in our app, as there was a lot of static data o be stored. The AO count triggered in a leap.

Later we created a common dynamic entity and saved all the static data in it. and filtered it on the basis of group type.

Thanks, You pointed a great point.

Great idea! 

The added value of one static entity does not reflect the value of one AO, and this will lead to worst development pattern and practices by the clients that, in the end, will affect the quality of the platform.

As an OS architect in a big Microsoft first consultant company, one of the competitive advantages of OutSystems vs Power Platform is the cost of scalability in terms of apps and users. If OutSystems uses every small detail to try to bring more revenue, that competitive advantage will fall.

Hello,

I completely agree with this point. Reducing the AO impact of static entities especially small ones would greatly help in simplifying development and reducing unnecessary complexity in projects.

Hope this can be considered in future improvements.

Thanks!

Agreed, @Kiet Phan  Thanks for bringing this up. 

Well thought out!  This makes sense. I agree with this. 

Agreed!!

Nowadays, to reduce AO usage, we often combine static entities into normal entities wherever feasible. 

Makes sense!

Agreed!

Avoiding static entities just to save AOs is crippling, and their resource impact is negligible—please rethink this policy, OutSystems. The platform is excellent, but this quirk punishes best practices and hurts ROI for companies.

Totally agree! 

I would be very happy to see this change in the future.

When I started working with OutSystems, I really loved the value Static Entities were bringing to create readable and easily maintainable applications. However, in practice I‘ve often seen developers avoiding them, or using sub optimal strategies like combining all static records under a single Static Entity for an application or environment.

I doubt changing the licensing to exclude them from the AO count could open the door to any sort of abuse to avoid using up AOs for standard entities due to the built-in limitations we have with static entities, but the advantages would really make a difference, especially for developers.

Agreed,

Static Entities should not be count as AO.
I just stopped to use it, we have better use for our AO's.

Agreed!

Agreed!

This idea has been trending at the top (consistently #1) for almost a year, which shows how important it is to OutSystems customers. It’s really disappointing that there is still no official response.

While implementing this feature would be a great first step, I believe we could go further by introducing an Enum primitive in the platform—similar to enums in high-code languages, as I describe in this idea.

@Tiago Ribeiro , I fully agree with your last post.

Best Regards

Hey I just added a way to save cost check my Idea 

https://www.outsystems.com/ideas/15154/how-to-avoid-static-entities-for-aos-saving-cost-and-bonus-multiple-filter/