Before you build
Limits — what's not built yet
Every gap below is real, current, and worth knowing before you commit an afternoon to a schema that assumes otherwise. This list exists so you find out here, not three screens into building something Aaly doesn't cover yet. Nothing here is a defect — it's the honest edge of what's shipped today. See Roadmap for what's planned.
Realtime
No WebSockets, push, or live subscriptions — every read is a plain
request/response REST call. Workaround: poll a search: true timestamp
field on an interval, or run a third-party realtime layer (Pusher, Ably,
Supabase Realtime) alongside Aaly, which stays your system of record.
Scheduled and failure-triggered functions
Server-side logic itself is built — see Functions — but a function only runs on a request. There's no cron or scheduled execution, and nothing fires on a failed (non-2xx) request. Workaround: trigger recurring work from an external scheduler (GitHub Actions, a cron box, any hosted cron) calling a custom endpoint; for failure handling, check the condition inside the function on the next successful call.
Auth: MFA, change-email, hosted pages
No multi-factor authentication, and no on-demand "sign out everywhere":
sessions revoke one at a time, though a password reset or change does sign out
every other session. email, phone and username are immutable once set, so
there is no "change my email" flow. Verification and password reset both
work (see Authentication), but there is no hosted reset page and
no configurable redirect after verification: your app collects the reset code.
Workaround: for MFA, put an identity provider in front; for a changed
email, create a new account and migrate the data.
Notification delivery
Sending email, Slack, WhatsApp and in-app messages works (see
Notifications), but delivery is not hardened yet: no
retry after a transient failure, no bounce or complaint handling, no opt-out
model, no scheduling or digests, no attachments, and no per-tenant rate limit.
Workaround: re-send explicitly on status: "failed", and keep your own
consent records for anything marketing-shaped.
Bulk operations
Bulk create, update, delete and upsert all work: send a JSON array to the
collection URL, up to 100 records per call, and you get a per-item result for
each one. GET /{entity}?id=A,B,C reads many by id in one request.
What is still missing is CSV or JSON import/export, and anything past that 100-record cap in one call. Workaround: batch client-side in chunks of 100. That is fine below a few thousand records; above that, talk to us.
RBAC and field-level permissions
Access control is tenant-level (see Multi-tenancy), not
role- or field-level. Every authenticated member of a tenant can read and
write every field on every entity that tenant can reach. Workaround:
model roles as a field on your users entity and enforce the distinction in
your own application logic — the platform won't do it for you yet.
Search
Every text field marked search: true has built-in word search: each
word in the query is matched against the words in the field, as the start of a
word, so ?name=sea finds "Search tips" and ?title=red car finds records
whose title has both a "red…" and a "car…" word, in any order. It runs on the
same index as every other filter and combines with them, which covers the
lookups a catalog, ticket queue or CRM needs. Relevance ranking, typo
tolerance and substring (contains) matching are not part of it.
Workaround: if you need those, send the same data to a dedicated search
service (Algolia, Meilisearch, Elasticsearch) alongside Aaly.
No dev / prod separation
Every project is live — there's no separate sandbox to reset. Records created while testing are real, persisted data. Workaround: keep a second project specifically for development; every pricing band includes at least two projects for exactly this reason.
Cursor pagination
Collection reads use limit/offset only — see REST API.
Fine through ordinary paging; not built for deep, high-throughput pagination
over very large result sets.
None of the above blocks the category Aaly is built for: multi-tenant business apps — CRM, ticketing, inventory, ops dashboards, internal SaaS — where the data is structured, the tenants are real organizations, and what changes over time is the schema, not the need for live sockets or bulk ETL. If your app leans hard on any of the gaps above, it's worth knowing now.