Skip to content
Manybases
esc

Search pages and sections. Try a tool name, an error code, a route.

↑↓ navigate↵ openesc close
  1. Guides
  2. Reference
  3. Limitations
Docs

Guides · Reference

Limitations

What Manybases does not do, on purpose or not yet, with the workaround when there is one.

In the data API#

  • No OR between filters. Two requests, or a different model.
  • No aggregations — sum, average, group by, count in SQL. Compute them in the front end or in an edge function. The table list gives each table's row_count to the management side.
  • No joins. The API serves tables; the front end assembles, or you denormalize.
  • No conditional visibility per row (draft / published): two tables, one prive, one lecture_publique.
  • No visibility per column (private e-mail, public nickname): two tables.
  • No custom roles or fine-grained permissions: eight presets, and the two space roles (admin, member).
  • One sort column, and no offset pagination.
  • One statement per SQL request, with a narrow grammar: no subqueries, no OR, at most 40 conditions.
  • No versioned migrations: apply_migration runs one DDL statement; the history keeps the text.

A limit is not a rule#

The publishable key is public, so anyone can send any request with it, ignoring your interface. A rule your front end enforces — "one check-in per day" — is a display convention. Server-side rules belong in an edge function; the only preset with a server-side limit of its own is formulaire (rate limit and row cap).

Around the product#

  • Up to 1,000 users per app on Builder and Studio, 3 on Free.
  • No point-in-time restore, no scheduled backups you can trigger. Your export is your backup — see Export, and its current bound of 40 files per export.
  • No realtime, no websockets, no scheduled tasks, no incoming webhooks.
  • No social login for the dashboard or for end users: e-mail and password, magic link.
  • No CSV import or export; SQL and the API are the ways in and out.
  • No mobile app yet.
  • No staging branches or environments: a second project is the way.
  • Sites: no rollback (redeploy from an earlier commit), no password or allow-list (a deployed site is public), one site per project, and the deployment history is not guaranteed complete.
  • Functions: execution output is not readable through any tool or screen yet; only their API requests are logged.
  • A function's call limits count per address: several people behind one address share them, and a function's daily limit does not stop someone who holds many addresses from using up the day.
  • Idempotency is honoured on the creation of rows, spaces, members and projects; not yet on updates, deletions, keys and functions; and on applying a shared secret to the functions already running.
  • A function's key cut by a redeploy or by rotate_function_secret can still be accepted for up to 10 minutes. Revoking its fn: entry cuts it from the next request on.
  • The request log purges on write: a project with no traffic keeps its last entries beyond 30 days.