Limitations

At platformOS, we aim to give you everything you need to build and run any web application smoothly. Whether you’re working on a Single-Page Application (SPA), a backend API for a mobile app, or a complex marketplace, our platform is designed to support you. We work hard behind the scenes to ensure your applications stay robust and responsive, even as your traffic grows and you accumulate more data.

However, as your application scales and data increases, it is important to be aware of potential performance impacts. Processes that work well with a certain amount of data might slow down as the data grows. The system still functions, but this indicates that you might need to optimize to keep things running smoothly. This section will help you understand these points and guide you in optimizing your platformOS applications to maintain performance. By being aware of the underlying technology and potential bottlenecks, you can ensure your applications run efficiently as they grow. Those limitations are meant to be a guideline for multi-tenant stacks. Private stacks can be configured per the specifications and requirements.

This page outlines the maximum limits and recommended usage, which may be further restricted by your usage plan. To fully utilize the capabilities of platformOS, an upgrade to a higher paid plan might be necessary. If you experience any performance issues or limitations, platformOS offers assistance through a Senior platformOS Developer Review or by providing a Dedicated Server Stacks Environment tailored to your needs - Contact Us

platformOS resources

Assets and Uploads

Depending on the provider, like S3 in multi-tenant stacks, the maximum file size for assets and user upload is 2GB.

Assets are best used for static content such as CSS, JavaScript, and layout images, etc. This is why a few thousand assets are expected. The system can handle much larger numbers, though you'll need to be mindful of performance as your asset count grows above the suggested threshold.

Uploads should be used for dynamic content - for example, to store product images, blog post images, documents, etc. You can have tens of millions of them and expect no issues.

Typically, issues arise when assets are used instead of user uploads.

Background Jobs

When creating a Background Job, you can specify a priority. This will affect the maximum execution time and how quickly the job will be processed. High-priority jobs need to finish faster and will take precedence over low-priority jobs.

We expect you to schedule up to a few thousand jobs to be invoked at some point in the future.

You should be mindful that all of the job arguments are stored in Redis when scheduling a job, and then have to be retrieved and deserialized to run the job. The general guideline is to keep the payload lower than 100KB. Redis has a hard limit of 512MB. To maintain efficient and reliable job processing, it is best to keep payloads as small as possible and pass only essential data in your Background jobs. If you need to handle large data sets, consider storing the data in a database or file storage and passing a reference (such as an ID or file URL) to the Background Job instead.

Form, Authorization Policies, Notifications, Layouts

We expect you to have up to a thousand configuration files for Forms, Authorization Policies, and Notifications. The system can handle much larger numbers, but you should be mindful of performance as your configuration file count exceeds the suggested threshold.

API Call Notifications

For API calls triggered from a web request context (synchronous), the default timeout is 5 seconds. You should not increase this timeout beyond 8 seconds because the page itself times out after 9 seconds (this is customizable in Private Stack).
The default timeout for Api Call trigger from a background job context (asynchronous) is 8 seconds. The soft limit (customizable in Private Stack) is 180 seconds.

Schema (Tables and Properties)

We expect you to have up to hundreds of tables and up to hundreds of properties in total, although we are running sites with tens of thousands of properties.

Records

To persist records, we rely on PostgreSQL. When a site starts slowing down, this is often the first bottleneck. For tables with up to a few thousand records, you can expect near-instant responses regardless of the queries you run. However, as your data grows to hundreds of thousands or millions of records, you'll need to be more mindful of how you write your GraphQL queries.

As your site scales, we monitor your queries to ensure that built-in and default indexes are used effectively. Even with millions of records, we work to keep everything running smoothly.

Our initial response to any performance degradation involves using our application performance monitoring tools to identify problematic queries. We then add dedicated database indexes or perform backend optimizations as needed.

In some cases, the best solution is to rewrite the query. When this happens, we provide detailed information about which endpoint and which GraphQL query is causing issues. Common issues include the use of or in GraphQL queries, or operators like ends_with (translated to LIKE '%..'.), and contains (translated to LIKE '%...%') which do not work well with PostgreSQL indexes.

As for the limits, the size of values in one Record cannot exceed 255MB. There is virtually no hard limit of the size of your database in total.

GraphQL

We currently do not put any restrictions in terms of the GraphQL complexity. We rely on you to be aware of the implications of using expensive operators and building complex queries. We are planning on improving platformos-check (which is used by platformOS Visual Studio extension) with GraphQL static analysis and warnings about potential performance problems with the larger dataset.

We expect you to have up to thousands of different GraphQL queries.

Pages

Our system was designed to leverage named parameters, and we expect you to have up to a thousand Pages. This might be problematic for hosting results of Static Site Generators, which might produce significantly more pages than this. We do host such sites as well, including DocsKit, which behind the scenes was built using Gatsby. We are currently not optimized for such a use case, however, it is in our Roadmap.

The most important limitation when it comes to Page is the execution time - we will throw 504 Timeout error after 9 seconds (configurable in a private stack). Typically issue hitting this limitation is not leveraging Background Jobs for potentially time-consuming and non-critical operations, like sending emails and API calls to a third-party system, etc.

To protect us from Denial-of-Service (DoS) attacks, our Web Application Firewall will block any IP that submits more than 300 requests within 5 5-minute period for about 10 minutes.

Partials

We expect you to have up to tens of thousands of partials.

Translations

We expect you to have a few thousand translations per language and tens of languages.

pos-cli deploy

There is no hard limit in terms of how many files can be deployed to platformOS.

You can upload gigabytes of assets (although in such cases, there is a high chance that you should be using Uploads instead of Assets).

There is a default soft limit of 90MB for the release.zip, which pos-cli generates with all of the configuration files - pages, partials, forms, translations, etc. (everything except assets). This limit is planned to be removed in 2025.

instance copy / data import / data export

Instance copy is a feature in Partner Portal that allows you to quickly move data and uploads from one instance to another, effectively creating almost a perfect copy (only background jobs are not migrated). We expect instance copy to work correctly for up to a couple of hundreds of thousands of records and gigabytes of uploads - the more records and data, the longer it will take.

Behind the scenes, instance copy relies on the data export and data import features, which have similar expectations.

Session

You can store values per session using session tag. It's important to note that sessions are stored in Redis. To optimize efficiency, it's advisable to keep payloads as small as possible and store only essential data in sessions. If you need to handle large datasets, consider storing the data in a database or file storage and passing a reference (such as an ID or file URL). A common example in the context of eCommerce is storing the ID of the current user's shopping cart as cart_id in the session, rather than storing an object with names of the products, prices, etc.

We do not enforce max length of the session, however we recommend you to set session expiration to as low as reasonable for your business rules.

Request Throughput

Ensuring optimal request throughput is crucial for maintaining the performance and responsiveness of your applications. As your traffic grows, horizontal scaling (adding more servers) and vertical scaling (enhancing server capacity) are effective strategies to manage increased load. Our platform offers the flexibility to implement both approaches, and our DevOps team is dedicated to ensuring that your applications can efficiently handle growth within your usage plan.

Additionally, we take proactive measures to manage the infrastructure and provision resources to accommodate large traffic spikes, such as those during events like Black Friday. If you run big advertising campaigns that will result in sudden increases in user activity, please notify us in advance. This allows us to overprovision resources to ensure your applications remain responsive and performant during these periods of high demand. Without prior notice, the service may experience temporary performance degradation as auto-scaling techniques require time to be activated.

Troubleshooting

If your solution is experiencing performance degradation or limitations and you are unsure of the cause, you can request a review by our senior team or discuss options for a private stack with us.