How to structure collections for an Adalo app
Give every real-world thing its own collection, store the values you filter or sort on directly on the record rather than through relationships, use the correct property type from day one, and name properties in lowercase with underscores. Most "Adalo is slow" and "I cannot filter this" problems are data-shape problems, not Adalo problems.
Your collections decide how hard every screen after them will be. Ten test records hide every mistake; a few hundred realistic ones surface all of them. This is how to lay them out before you build screens.
One collection per real-world thing
Properties like status_2 or notes_extra are a sign that a second thing is hiding inside one collection. Split it out and relate the two.
- A booking app needs Users, Services, Bookings and Reviews, not one Bookings collection.
- Duplicate-sounding property names usually mean a missing collection, not a missing field.
- Relate the split collections rather than merging their data back together.
Store what you filter on
Adalo filters fastest on plain properties sitting directly on the record. Reaching through relationships forces Adalo to resolve more data per record.
- Filtering by category? Keep a category property on the record itself.
- Duplicating a value onto the record is deliberate, not a mistake.
- Relationship filters are what makes long lists crawl.
- Source of truth stays in the relationship; the copy is only for filtering.
Pick the right property type on day one
Changing a type later means fixing every component bound to it. Numbers stored as text cannot be sorted or compared; dates stored as text cannot drive "before today" filters.
- Number for anything you sort, sum or compare.
- True/False for states with exactly two options.
- Date & Time for anything time-based, even if you only show the date.
- Text for IDs, even numeric-looking ones you never do maths on.
Name properties the way you will read them
Lowercase with underscores stays predictable in URLs, API responses and Magic Text alike: order_total, created_at, customer_email.
- Avoid spaces and punctuation in property names.
- Keep booleans positive: is_active, not not_disabled.
- Prefix related IDs clearly: customer_id, product_id.
- Use the same name for the same concept across collections.
Test with realistic volume
Load a few hundred realistic records before building screens, not just enough to click through the demo.
- Check lists still feel fast on a phone, not just in Preview.
- Confirm filters you assumed would work actually have the property they need.
- Test with messy data: empty fields, long text, duplicate names.
Common mistakes and how to diagnose them
A list gets noticeably slower as records grow.
- Likely cause:
- Filters or visibility rules reaching through relationships on every record.
- Fix:
- Copy the value you filter on onto the record itself and filter on that property directly.
You cannot filter by a date range.
- Likely cause:
- The date is stored in a Text property.
- Fix:
- Add a proper Date & Time property, migrate the values, and rebind the filter.
Deleting a record leaves broken screens.
- Likely cause:
- Other records still point at the deleted one through a relationship.
- Fix:
- Use an is_archived flag and filter it out of lists instead of hard-deleting records users may still reference.
Real example: a marketplace that could not filter by city
A services marketplace stored city only on the Provider record. Every Listings screen needed "listings in my city", so each record had to resolve its provider before the filter could run, and the list took seconds to paint on mobile.
Copying city onto the Listing at creation time made the filter a single top-level comparison. Same data, same screens, instant lists. It is the change I make most often on Adalo apps that feel slow.
When you need an Adalo expert
Plenty of Adalo issues are straightforward to fix yourself with the steps above. It usually pays to bring in an experienced Adalo developer when the problem sits deeper in the build:
- You are already live and need to restructure collections without losing production data.
- The app needs multi-tenant separation, teams, organisations or clients that must never see each other's records.
- Some of your data has to live in an external system and stay in sync with Adalo collections.
Related guides
How to connect an external collection to Adalo
Step-by-step: get a REST endpoint Adalo accepts, add it under Database → External Collection, and bind the properties to your lists and forms.
Why is my Adalo app slow?
The common causes of a slow Adalo app, heavy lists, relationship filters, oversized images and unnecessary data, and what to change for each.
How to set up login and user permissions in Adalo
Signup, login, password reset and role-based access in Adalo, including how to stop one user seeing another user's records.
Frequently asked questions
Should I store images in the collection?
Store the URL in the collection and keep the file in storage, that is exactly what the Multi Image Picker does for you.
How many collections is too many?
There is no hard limit. Too few is the more common problem: one collection doing several jobs.
Should I use relationships or copy the value?
Use relationships for the source of truth, and copy small values you filter or sort on frequently onto the record.
Can I change a property type later?
You can add a new property of the correct type and migrate, but you cannot safely convert in place, every bound component needs rebinding.
How do I handle soft deletes?
Add an is_archived True/False property and filter archived records out of every list.
Webnux Tools is an independent product by Webnux Ltd. It is not affiliated with, endorsed by, or sponsored by Adalo, Inc. Adalo is a trademark of Adalo, Inc.