Base44 Introduces Database Size Limits by Plan
Base44Base44 now applies a database size limit to each app and a maximum size to each record, both based on the plan. The limits cover apps created from October 18, 2026 onward, and usage is shown on the Database card of an app's App usage page.
Key Takeaways
- Every app database created from October 18, 2026 now has a size cap, and the size of the cap depends on the builder's plan.
- A maximum size per record applies as well, which matters most for apps that store large payloads inside a single entry.
- Apps created before October 18, 2026 are not retroactively limited, so existing projects keep working as they did.
- Usage is visible on the Database card of an app's App usage page, giving an early warning before a limit is reached.
- Storage becomes a plan differentiator alongside credits, which can push data-heavy projects onto higher tiers.
- The change shipped under Base44's Data & media area in the product changelog, not the developer changelog.
Database Capacity Becomes a Plan Feature
Base44 introduced size limits on app databases. Each app's database now has a cap on its total size, and each individual record has a maximum size, with both values depending on the plan the account is on. Until now database capacity was effectively open-ended, so this is a new constraint builders have to design around rather than a new capability.
Which Apps Are Covered
The limits apply to apps created from October 18, 2026 onward. Apps that already existed before that date are not retroactively capped, so running projects are unaffected by the change.
Seeing How Much Is Left
Base44 surfaces the usage directly in the product: the Database card on an app's App usage page shows how much of the limit an app is consuming. That makes it possible to spot an app approaching its cap while there is still time to prune data or move up a plan, instead of discovering the ceiling when a write fails.
Why It Matters
Storage joins credits as a plan-differentiated resource on Base44, which changes how builders should size data-heavy projects. Apps that keep many rows, or that store large payloads inside single records, are the ones most likely to run into the per-record maximum, and they now have a reason to check the documented limits for their plan before the build rather than after.