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 and password reset
No multi-factor authentication, no password-reset flow, and no "sign out everywhere" — sessions revoke one at a time. Access tokens last an hour and refresh automatically. Workaround: handle password reset through your own email flow against the users entity; use an API key for long-lived server-side integrations.
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
Exact and prefix matching only (eq/starts on text fields) — no fuzzy
matching, no relevance ranking, no typo tolerance. Good enough for a typical
SMB catalog, ticket queue, or CRM; not a general search engine.
Workaround: for anything needing real relevance ranking, index the same
data in 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.