Base44 cannot server-render pages for visitors (search engines and AI crawlers get a prerendered version, visitors get client-side rendering), cannot let you set a Content-Security-Policy or HSTS header (only iframe embedding and Permissions-Policy are configurable), cannot bill digital goods through App Store or Google Play billing, does not support unique constraints or document multi-entity transactions, cannot hold protected health information without Base44's prior written agreement, and offers no SLA, workspace audit logs or customer-held encryption keys below Enterprise. Several older limits are gone: realtime over WebSockets (entity subscriptions and actors), bulk deletes and updates, row-level and field-level security, and a backend service role now exist. Plan around what remains before you build.
Why this matters
Knowing a platform's limits in advance is cheaper than discovering them in production. Base44 is excellent for what it is — fast prototyping and generative app construction. It also has structural limits that are easy to miss in the marketing copy. This article, written by the lead engineer at Base44Devs, lists the limits that Base44's own documentation, terms and security page still confirm, each vendor fact with a read date, the workaround where one exists, and the honest answer of "you cannot do this here" where none does. It also marks the limits Base44 has since closed, because an out-of-date limitations list steers platform decisions the wrong way.
This is not a hit piece. It is a reference. Use it for platform-choice decisions. Save it for the next time someone on your team says "let's just sell the premium tier inside the iPhone app" or "let's just store medical records here" without checking what the platform actually supports.
Architecture limits
Realtime now exists: entity subscriptions and actors
Earlier versions of this page said Base44 had no WebSockets; that is no longer true. Entity subscribe() "establishes a WebSocket connection to receive instant updates when any record is created, updated, or deleted" (Base44 entities SDK reference, read 17 Oct 2026), and "Realtime events follow your entity's security rules" (Base44 SDK data guide, read 17 Oct 2026). For shared live sessions, "An actor is a long-running backend process that multiple clients connect to simultaneously", offering "Realtime messaging: Send and receive messages with clients via WebSockets", per-session storage, and scheduled ticks and wakes (Base44 actors overview, read 17 Oct 2026). Base44's CLI skill calls actors "the realtime/WebSocket primitive behind multiplayer, collaborative boards, presence and live cursors, in-room chat, and live auctions" (Base44 CLI skill, read 17 Oct 2026).
What remains: actors are defined in code and deployed with base44 actors deploy; "Ticking needs at least one connected client"; an actor's this.client "uses anonymous authentication", so elevated writes go through this.client.asServiceRole after you validate the message; and actors belong to Base44's backend service, which its docs call "currently in beta" (Base44 backend pricing, read 17 Oct 2026).
Workaround: none needed for chat, presence or live collaboration. Server-Sent Events are not documented; use a subscription or an actor.
A service role exists, with all-or-nothing access
Backend functions are no longer limited to the calling user's permissions. base44.asServiceRole "bypasses both RLS and FLS entirely", and "It's only available in Base44-hosted backend functions, and your function is responsible for any access checks it needs" (Base44 entity security docs, read 17 Oct 2026). Webhooks and other plain HTTP calls carry no user, and the docs say: "Use asServiceRole for all operations in these cases" (Base44 backend functions docs, read 17 Oct 2026). The limit is granularity: the docs describe one service role, with "full read and write access to every entity and record in the app", and say to "Use it only for trusted backend logic" (Base44 SDK data guide, read 17 Oct 2026). There is no scoped or read-only service identity.
Workaround: keep service-role code small and inside backend functions, check the caller's role or a shared secret before any elevated read, and log what each elevated call touched.
No built-in tenant model
Base44 has no tenant or organization object for your app's users; the documented pattern is to model Company or Team entities yourself and link them to the built-in User entity (Base44 app data docs, read 17 Oct 2026). Enforcement is server-side, though: the documented multi-tenant setup is an Entity-User Field Comparison rule matching a company_id on each record to the same property on the signed-in user, so "Each person only sees records that belong to their company" (Base44 security settings docs, read 17 Oct 2026). The platform does not apply that rule for you: every entity holding tenant data needs its own rule, and service-role code skips all of them.
Workaround: put the tenant rule on every tenant-scoped entity before launch, run the security scan, and use Test Permissions in preview as a user from each tenant.
Client-side rendering for visitors (crawlers get a prerendered version)
Base44 apps render client-side for visitors, but Base44 serves search engines and AI crawlers a prerendered version of each page — real headings, content, meta tags and structured data — refreshed "when you publish or your content changes" (Base44 SEO docs, read 17 Oct 2026). The limits that remain are narrower: if a rendered version is not ready yet, crawlers get a fallback summary of the page's heading, description and links; per-page meta descriptions are not set by default; pages with URL parameters do not get a unique meta title; and every visitor still waits for the JavaScript bundle before content appears. When a Base44 app does not show in Google, check configuration first — the SEO toggle switched off (which disables prerendering), pages behind login or set to noindex, or a new domain Google has not crawled yet. We walk through that diagnosis in why a Base44 app is not showing in Google.
Workaround: keep the SEO toggle on and set meta descriptions from the SEO & GEO page. If first-load speed on public marketing routes matters, a Cloudflare Worker or Vercel rewrite that serves pre-rendered HTML to every visitor still helps. Adds setup complexity but works.
Single region
Base44 stores app data in the US by default. On an Enterprise plan (Business or Enterprise), a workspace can store app data in EU or UK clusters instead, and workspaces created before 1 October 2026 can also do this on Elite. The setting covers apps created after 16 April 2026; media files follow the chosen region only in apps created from 12 October 2026 (with UK residency they are currently stored in the EU), and account details and billing information stay in the US (Base44 privacy and security docs, read 17 Oct 2026). That is a choice of one region, not multi-region serving: users far from your app's region pay round-trip latency on every request, and there is no multi-region deployment option.
Workaround: edge caching for read-heavy public pages via Cloudflare. Mutations still incur the round trip.
Cold starts on backend functions
Backend functions run on Deno Deploy, and their logs include "system-level entries from Deno Deploy, such as isolate startup times" (Base44 CLI logs docs, read 17 Oct 2026). The docs describe no warm-pool or minimum-instance setting, and every run is capped: "Backend functions have a maximum execution time of 5 minutes" (Base44 backend functions docs, read 17 Oct 2026).
Workaround: measure first with base44 logs, keep imports light on latency-sensitive functions, and split long jobs into shorter calls or workflow steps. If you ping a function to keep it warm, each ping is a billed invocation; the Credits docs put 100 invocations at about 1 integration credit.
Data layer limits
Bulk writes now exist, but skip entity automations
This used to be a gap; it is not any more. The SDK documents deleteMany(query), which "Permanently removes all records that match the provided query", alongside updateMany(), bulkUpdate(), bulkCreate() and upsert() (Base44 entities SDK reference, read 17 Oct 2026). Batch sizes are documented: updateMany() results "are batched in groups of up to 500", and bulkUpdate() and upsert() take up to 500 records per request. The catch is event-driven logic: "Entity automations only fire for single-record create, update, and delete calls made through the entities API", so a bulk or by-query write skips every entity automation on that entity (Base44 automations docs, read 17 Oct 2026).
Workaround: the docs' own advice — if an automation must react to every change, "avoid bulk or by-query writes on that entity, or trigger the automation's logic manually instead."
Default-permissive entities
An entity without rules is open: "If no RLS is defined, all records are accessible to all users" (Base44 CLI skill reference, read 17 Oct 2026). In the app editor, "Base44 automatically sets up data permissions as you build your app" (Base44 security settings docs, read 17 Oct 2026), and the security scan, available on every plan, flags "a data table is missing permission rules, or when people have more access than they should" (Base44 security scan docs, read 17 Oct 2026). The protection is the rule on the entity, not a filter in the page: under a read rule, list() and filter() return "an empty result, the same as if nothing matched" for records the caller may not see (Base44 entity security docs, read 17 Oct 2026). Discussed in detail in the SDK reference and security checklist.
Workaround: give every entity that holds per-user data a read rule, rescan after schema changes, and test as a second user with Test Permissions in preview.
Database size limits by plan, and no published performance figures
Base44's docs now cap each app's database by plan: "Your plan sets how much data each app can store in its database, and how large a single record can be. These limits apply to apps created from October 18, 2026. Apps created before then don't have them." The caps run 200 MB on Free, 2 GB on Starter, 5 GB on Builder, 10 GB on Pro, 25 GB on Elite, 50 GB on Business and no limit on Enterprise; the largest record is 100 KB on Free, Starter and Builder, 250 KB on Pro, Elite and Business, and 1 MB on Enterprise. When the database is full, the app "can't add new records", though you can still edit and delete. Uploaded files "are stored separately and don't count toward it", and the media guide says "There's no overall limit on the files your app stores, only on the size of each file" (Managing your app data, read 20 Oct 2026). What the docs do not publish is how an entity performs as it grows: there is no record-count guidance and no latency figure to plan capacity against.
Workaround: watch the Database card on the app's usage page (shown for apps created from 18 October 2026), track entity size with count() instead of fetching records, compute totals server-side with aggregate(), and plan a migration for any entity whose list scans or filters start slowing down.
5,000-record-per-request limit
"Starting November 27, 2025, there is a limit of 5,000 items per request", and the dashboard's data table "only shows up to 5,000 items, even if your collection contains more" (Base44 app data docs, read 17 Oct 2026). In the SDK's options form, a page holds "up to 5,000" records and defaults to 100.
Workaround: cursor pagination is built in. list() and filter() return next_cursor and has_more, and "Records added or deleted between pages never shift the boundary" (Base44 SDK data guide, read 17 Oct 2026).
MongoDB-style queries, but no built-in search
Base44 says "The database is MongoDB compatible, allowing you to use all MongoDB operators when querying through the SDK" (Base44 backend features, read 17 Oct 2026). The SDK reference types $regex for string fields and $all and $size for arrays, and aggregate() returns server-side counts, sums, averages, minimums, maximums or distinct counts, "up to 1,000 rows" (Base44 entities SDK reference, read 17 Oct 2026). What the docs do not describe is search: no text index, relevance ranking or geospatial query is documented.
Workaround: for full-text or ranked search, index the data in Meilisearch or Algolia from a backend function. For geo, store coordinates and filter a bounding box with $gte and $lte, then refine distances in code.
No transactions across entities
The SDK reference documents no transaction or multi-entity atomic write, and even single-call bulk updates are batched: updateMany() works in groups of up to 500 and reports has_more when there is more to do. If a multi-entity update fails partway, nothing rolls the earlier writes back. Base44's actor docs give the same advice for retries: "Make writes safe to repeat, because the session can run a handler again after an error" (Base44 actors reference, read 17 Oct 2026).
Workaround: design schemas to avoid the need for cross-entity transactions. Idempotent operations (upsert() on a natural key helps). Compensating writes on failure.
Entity changes are logged, with no published retention
Each app's Logs page now records "entity operations (created, updated, deleted, restored)" alongside user and function events, filterable by event type, user email and errors (Base44 app logs docs, read 17 Oct 2026). On the Elite plan and on an Enterprise plan (Business or Enterprise), Backup & Restore also keeps point-in-time copies of your tables: "Elite keeps 7 days of backups, and Business and Enterprise keep 30 days" (Base44 Backup & Restore docs, read 17 Oct 2026). The docs give no retention period and no export for the Logs page, so it is a troubleshooting tool rather than an audit trail you can hand to an auditor.
Workaround: for a durable change history, write to an AuditLog entity from the backend functions that change data.
No index controls or unique constraints
Entity schemas define fields, types and validation, with no index settings, and "Base44 entities don't support unique constraints" (Base44 entity schemas docs, read 17 Oct 2026). The docs' own duplicate check — look for an existing record in a backend function before creating one — "narrows the window for duplicates but doesn't close it."
Workaround: write through upsert() on a natural key, find duplicates afterwards with aggregate() grouped by that key with a having count above 1 (a documented example), and mirror data to a database you control when a query pattern needs a real index.
Authentication and identity limits
Two built-in roles; finer roles are fields plus rules
The built-in User role is "Either admin or user" (Base44 User schema docs, read 17 Oct 2026). Finer roles no longer need backend code. Base44's answer to "Can I create more roles than just user and admin?" is "Yes": add a field such as access_level to the User table and use User Property Check rules on it (Base44 security settings docs, read 17 Oct 2026). Rules cover create, read, update and delete separately and accept templated conditions such as {{user.email}} and {{user.data.department}} (Base44 entity security docs, read 17 Oct 2026). One inconsistency: those developer docs document field-level security in the entity schema, while the editor's permissions FAQ still answers "No. Permissions apply to entire data tables, not individual fields."
Workaround: model roles as User fields with a rule on each entity; set field-level rules in the schema's rls block and verify them with Test Permissions in preview.
App SSO is OIDC-only and plan-gated
Google OAuth and email/password are first-class. Single sign-on through an OIDC identity provider — Google, Microsoft, GitHub, Okta, Apple, Kakao, or a custom IdP — needs an Enterprise plan (Business or Enterprise) on workspaces created on or after 1 October 2026; workspaces created before that date keep the earlier Elite-or-higher requirement (Base44 SSO docs, read 17 Oct 2026). The docs describe OIDC only, so an enterprise customer whose identity provider speaks SAML alone has no documented path.
Workaround: on a plan without app SSO, or for a SAML-only identity provider, route through Auth0 or Clerk via a backend function. Adds cost and complexity.
JWT in local storage
"Base44 stores authentication tokens in the browser's localStorage. HttpOnly cookie storage is not currently available" (Base44 security overview, read 17 Oct 2026). Tokens are therefore readable by any script running on the page. The default session lasts "up to 90 days" (Base44 app store docs, read 17 Oct 2026), and the docs describe no setting to shorten it.
Workaround: sanitize all rendered content, keep third-party scripts off signed-in pages, and keep sensitive actions behind backend checks. Cannot fully eliminate the risk.
No MFA for your app's own users
Base44's two-factor authentication protects Base44 accounts — the people building apps — and requiring it for every workspace member needs an Enterprise plan (Business or Enterprise) (Base44 workspace SSO docs, read 17 Oct 2026). For the people who sign in to your app, the login docs describe email and password, social providers and OIDC SSO, but no MFA option, so there is no per-user or per-role MFA to enforce (Base44 login docs, read 17 Oct 2026).
Workaround: route sign-in through an identity provider that enforces MFA — app SSO on a plan that includes it, or Auth0 or Clerk wired through a backend function.
Integration limits
Custom integrations need an OpenAPI spec and a Builder plan
Custom integrations are a current feature, not a deprecated one. Base44's product changelog added workspace-level custom OpenAPI integrations, and its docs describe the flow: import an OpenAPI or Swagger spec, expose up to 30 operations, and call them from any app in the workspace via base44.integrations.custom.call(), with auth headers stored as encrypted workspace secrets that are never sent back to the browser (Base44 custom integrations docs, read 17 Oct 2026). The limits are in the fine print: only workspace admins and owners on the Builder plan or higher can create one, and an API without an OpenAPI or Swagger spec cannot be registered this way.
Workaround: for an API with no spec, call it from a backend function that reads its key from the app's secrets.
Webhooks land on backend functions you secure yourself
Earlier versions of this page said webhooks fired only while users were active; Base44's docs describe no such dependency and we could not verify the reports, so that claim is withdrawn. Backend functions need the Builder plan or higher (Base44 integrations docs, read 17 Oct 2026). Each one "gets its own HTTP endpoint for webhooks and external integrations", and a webhook call carries "no authenticated user context", so the function runs as the service role and must verify the sender itself (Base44 backend functions docs, read 17 Oct 2026). The security scan suggests "a provider signature for a webhook" and warns that its one-click fix for open functions "rejects any caller that has no signed-in user, so it can break" a webhook (Base44 security scan docs, read 17 Oct 2026). Runs are capped at 5 minutes, and waitUntil() background work "is best-effort. It isn't guaranteed to complete or retry".
Workaround: verify the provider's signature, respond fast, store the event as a record, and do slow work in a workflow or scheduled automation that reads those records.
Built-in email uses a shared sender until you add your domain
By default, built-in emails go out from the generic no-reply@base44-apps.com address, a sending identity you do not control. From the Starter plan you can send from your own domain instead, authenticated with 3 CNAME records Base44 gives you, at about 2 integration credits per email instead of about 1 (Base44 custom email domain docs, read 17 Oct 2026). Other documented limits: one custom email domain per app, "Built-in emails do not support external mailing lists", and emailing an address that has not signed up needs a paid plan and a verified custom domain, one recipient at a time (Base44 sending emails docs, read 17 Oct 2026).
Workaround: for marketing or higher-volume sending, Resend (Builder plan and above) or another provider called from a backend function, on your own domain with SPF/DKIM/DMARC.
No App Store or Google Play billing for digital goods
Web payments are not the limit: Stripe apps gained a Subscriptions tab (29 Sep 2026), every app owner can refund from the Payments transactions page (23 Sep 2026), and Base44 Payments added a Payouts tab (6 Oct 2026) (Base44 product changelog, read 17 Oct 2026). The limit is in the mobile apps Base44 builds. Asked "Can I charge for digital content in my mobile app?", the docs answer "Not yet. Apple and Google both require their own billing systems for anything digital, and Base44 does not support them yet", and add that "RevenueCat's native SDK and Capacitor in-app purchase plugins need access to the native layer that Base44 apps do not expose, so they do not work" (Base44 app store docs, read 17 Oct 2026).
Workaround: the docs' own pattern — sell the subscription on the web version with Stripe, and have the mobile app check who has paid and show or hide the content, with nothing in the app opening a payment flow.
Managed OAuth covers catalog connectors only
For the services in Base44's connector catalog, "Base44 handles the OAuth flow and credential storage", either through one shared account for the app or with each signed-in user connecting their own account (Base44 connectors docs, read 17 Oct 2026); connectors need the Builder plan or higher (Base44 using connectors, read 17 Oct 2026). Outside the catalog there is no managed OAuth: custom OpenAPI integrations store auth headers as workspace secrets, so a provider that needs its own OAuth flow, such as device flow or a multi-step consent, means building the authorization, token storage and refresh yourself.
Workaround: check the catalog first (base44 connectors list-available prints it, and the dashboard has Request a connector); otherwise build the flow in a backend function and keep tokens in secrets or in an entity protected by rules.
Performance limits
A Cloudflare CDN you cannot configure
"Base44 automatically uses Cloudflare CDN for caching and delivery", republishing refreshes the cached files, and "Currently, you can't clear the CDN cache manually" (Base44 app performance docs, read 17 Oct 2026). The docs describe no cache-header settings, so you cannot set long-lived caching for fingerprinted assets. Protocols are not the problem: on 17 Oct 2026, two Base44-hosted apps answered over HTTP/2 and advertised HTTP/3 (alt-svc: h3=":443") through Cloudflare, so the earlier "no HTTP/2 or HTTP/3 controls" entry is dropped.
Workaround: republish to refresh cached files; for your own caching rules, put a CDN in front of a custom domain.
Credit cost scales with load
"Running a backend function can use a small amount of integration credit. 100 invocations use about 1 credit", and anything the function does is charged on top: an LLM call, an email (about 1 credit, about 2 from a custom email domain), a file upload. Calling an external service with your own API key uses no integration credits (Base44 credits docs, read 17 Oct 2026). Self-serve plans include from 100 integration credits a month on Free to 50,000 on Elite (base44.com/pricing, read 17 Oct 2026), and "When you reach your credit limit, actions that use credits pause until your next reset."
Workaround: cache aggressively at the edge, pre-compute results in entities, keep AI and email calls off hot paths, and apply the security scan's credit-protection fix so outsiders cannot spend your credits.
Security limits
No WAF, CORS or CSP settings of your own
Base44 rate-limits for you ("All public endpoints are rate-limited by default", Base44 security overview, read 17 Oct 2026), and its auth SDK accepts an "Optional Cloudflare Turnstile CAPTCHA token for bot protection" on login and registration (Base44 auth SDK reference, read 17 Oct 2026). You cannot configure firewall rules (the docs describe none), CORS ("Per-app CORS configuration is not currently available") or other response headers: beyond iframe embedding (X-Frame-Options) and Permissions-Policy, "Other HTTP-level headers, such as Content-Security-Policy and Strict-Transport-Security, are not configurable at the individual app level." HSTS is present anyway: two Base44-hosted apps we checked on 17 Oct 2026 sent strict-transport-security: max-age=31536000, and neither sent a CSP.
Workaround: Cloudflare in front of your custom domain for WAF rules, bot management and a CSP header. Custom domains start on the Starter plan.
No log retention beyond platform default
Function logs are short-lived: the logs API returns "up to 500 lines from the last 7 days" by default, and "Logs are kept for a limited time, so a window far in the past can come back empty" (Base44 function logs API, read 17 Oct 2026). The docs describe no setting to keep them longer. Forensic investigation after an incident requires logs you've shipped externally.
Workaround: ship the lines you need from each function to your own log store, or pull them on a schedule with base44 logs. Shipping with waitUntil() keeps responses fast but is best-effort, so keep critical records synchronous.
Customer-held encryption keys are Enterprise-only
By default, workspace API keys and integration credentials "are encrypted at rest using AWS Key Management Service, and they are protected by a key that Base44 manages for the platform" (Base44 security overview, read 17 Oct 2026). Backend functions read secrets at runtime with secrets.get(). On the Enterprise plan, a workspace can get its own dedicated key, or bring its own: "BYOK is available on the Enterprise plan", and "Base44 can only use the key through a permission you add to the key's policy". It covers secrets and OAuth tokens, not records: "Your key doesn't encrypt your apps' data" (Base44 BYOK docs, read 17 Oct 2026).
Workaround: below Enterprise, a vault you administer (1Password Connect, Doppler) accessed from a backend function at request time.
Workspace audit logs need the Enterprise plan, not Business
Below Enterprise you still get an app-level trail: each app's Logs page records logins, role changes, entity schema changes and publish and unpublish events (Base44 app logs docs, read 17 Oct 2026). The workspace-wide record — member and billing changes, sign-ins, publishing and governance events, streamable to your own monitoring tools — comes through the Audit Logs API, which the docs say is "available on the Enterprise plan, not the Business plan" (Base44 app logs docs; base44.com/security, read 17 Oct 2026).
Workaround: below Enterprise, keep an AuditLog entity, populated from backend functions, for the events a security review will ask about.
Compliance and operational limits
No SLA below Enterprise
Base44 publishes no uptime SLA for self-serve plans; its security page says "Detailed commitments are available to Enterprise customers as part of their Service Level Agreement" (base44.com/security, read 17 Oct 2026). The Terms of Service (last updated 22 June 2026) say the company does not guarantee the platform will be "uninterrupted, error-free, timely, or secure".
Workaround: factor outage exposure into your business risk. Maintain a documented exit plan.
SOC 2 covers the platform, not your app
Base44 states its platform holds SOC 2 Type II and ISO 27001 certification and is independently penetration-tested, with the SOC 2 report and a GDPR DPA available on request (base44.com/security, read 17 Oct 2026). That covers Base44's own controls; it does not attest your app's configuration (row-level security, secrets, auth rules), which a security questionnaire will still ask about. Base44's docs say it plainly: "You are responsible for your app's security settings" (Base44 security overview, read 17 Oct 2026).
Workaround: request Base44's SOC 2 report for the platform half of a vendor review, and document the app half yourself: who can read which entity, where each secret lives, how sign-up and roles are enforced. If a customer requires a control the platform does not let you configure, that app has to move to infrastructure you control.
No published HIPAA BAA
Neither Base44's docs nor its security page mention HIPAA or a Business Associate Agreement (read 17 Oct 2026). Its Terms of Service (last updated 22 June 2026) say that no "protected health information or credit, debit or other payment card data" will be shared with the platform "other than if expressly agreed by the Company in prior writing and the appropriate agreement is in place."
Workaround: without that written agreement, PHI cannot go on the platform. For healthcare apps, the data layer must move off-platform.
Support covers the platform, not your app
Base44 support "does not provide hands-on debugging or fixes for your individual app code, prompts, or architecture", and "Response times vary based on ticket volume and issue urgency" (Base44 support docs, read 17 Oct 2026). The only guaranteed response times the docs mention come with priority support on an Enterprise plan (Business or Enterprise) (Base44 for enterprises, read 17 Oct 2026); Elite lists premium support (base44.com/pricing, read 17 Oct 2026).
Workaround: do not depend on platform support for incident resolution or app-level debugging. Build your own runbook.
Compliance and exit limits
GitHub sync needs the Builder plan
"GitHub 2 way sync requires the Builder plan or higher" (Base44 GitHub docs, read 17 Oct 2026), and base44.com/pricing lists GitHub integration from Builder up.
Workaround: budget for Builder from day one if you might ever want the code in your own repository.
Exported code still depends on the SDK
The code export (Builder plan or higher) "includes all client-side code (HTML, CSS, JavaScript, assets) and backend functions", but asked what cannot be exported, the docs answer: "Managed hosting, authentication system, or database infrastructure" (Base44 mobile and export docs, read 17 Oct 2026), and the project's package.json "(includes @base44/sdk)" (Base44 project structure docs, read 17 Oct 2026). You can host the frontend elsewhere and keep "the Base44 backend services" (Base44 backend features, read 17 Oct 2026), but running independently means re-implementing every SDK call. base44 eject clones an app into a new Base44 project, and "The ejected project has an empty database."
Workaround: see vendor lock-in deep dive. Migration is engineering work, not a config change.
No one-step database export
Base44 now documents data export, but one table at a time: each table downloads as CSV from the Data page (with a search or filter on, only matching records), and on the Elite plan and on an Enterprise plan (Business or Enterprise), Backup & Restore downloads a table as it was at an earlier point (Base44 app data docs; Base44 Backup & Restore docs, read 17 Oct 2026). Schemas come out separately: base44 eject downloads entity schemas but not data, while with GitHub two-way sync "entities are managed in Base44 and are not included in your local repository" (Base44 project structure docs, read 17 Oct 2026). There is no single dump of every table with its schema.
Workaround: a backend function that walks every entity with cursor pagination (list() returns next_cursor and has_more) as the service role, so row-level rules don't hide records, and writes JSONL to external storage in chunks that finish inside the 5-minute limit. We covered this in schema migration best practices.
GitHub sync runs on Base44's terms
The old one-way Export to GitHub is now a legacy setup; the current integration syncs both ways, pushes every change to the connected repository automatically with no manual push, and only syncs back from a default branch named main. "Sync can't be paused, so the only states are connected and disconnected" (Base44 GitHub docs, read 17 Oct 2026).
Workaround: trust the export but verify. Audit the exported repo before using it as a migration source of truth.
What this means for platform choice
The limits are not a verdict on Base44. They are constraints to plan against, and they map directly onto which use cases Base44 is actually suited to — internal tools can live with gaps that customer-facing SaaS cannot.
Base44 is a good fit if:
- You are prototyping or MVPing.
- Your data does not require regulatory compliance.
- Your traffic profile is bursty but moderate.
- You are willing to invest in workarounds for the structural gaps.
- You have a documented exit plan you can execute if you outgrow the platform.
Base44 is a bad fit if:
- You need to sell digital goods inside an iOS or Android app.
- You are storing PHI or card data without Base44's written agreement.
- You need multi-region performance.
- You need a contractual SLA without an Enterprise contract.
- You cannot afford the engineering time to fight platform-specific issues.
The decision framework is in our is base44 production ready article. The migration playbooks for when you decide to leave are in our migration index.
Common limitation mistakes
Discovering limits in production. Read the limits before you build. This article exists for that reason.
Trusting AI-generated code without checking the names. Base44's own SDK skill for coding agents carries a "Do Not Hallucinate APIs" table, for example functions.call() where the real method is functions.invoke(), and onAuthStateChanged() where the SDK offers me() (Base44 SDK skill, read 17 Oct 2026). Check method names against the SDK reference before you ship.
Planning from an old limitations list. Realtime, bulk delete, field-level permissions and a service role were all gaps on older lists, this one included, and Base44's changelog moves weekly. Some gaps hold: unused credits still "expire when they reset" (Base44 credits docs, read 17 Oct 2026). Base44 publishes a roadmap view on its feature-request board, but a roadmap entry is not a ship date. Re-check a limit against the docs before you design around it or rule the platform out over it.
Treating "workaround" as "free." Every workaround costs engineering time and operational complexity. Sum them up before deciding the platform is cheap.
Limitation summary
| Category | Critical limits |
|---|---|
| Architecture | Client-side rendering for visitors, single data region, no built-in tenant model, 5-minute function runs |
| Data | Open entities when no rules are set, no unique constraints, no documented transactions, no built-in search, 5,000 records per request |
| Auth | Tokens in localStorage, two built-in roles, no MFA for app users, app SSO OIDC-only and plan-gated |
| Integrations | Custom integrations need an OpenAPI spec and Builder+, no App Store or Google Play billing for digital goods, managed OAuth for catalog connectors only |
| Performance | CDN cache you cannot clear or configure, cold starts, credit use pauses at the limit |
| Security | No WAF, CORS or CSP settings, workspace audit logs and customer-held keys Enterprise-only |
| Compliance | No SLA below Enterprise, SOC 2 covers the platform only (not your app), no published HIPAA BAA |
| Exit | SDK lock-in, per-table data export, GitHub sync on Builder+ only |
| No longer limits | Realtime (entity subscriptions, actors), bulk deletes and updates, row- and field-level security, backend service role |
Want us to assess your fit against the platform?
Our $497 audit produces a written platform-fit assessment for your specific app, identifying which limits will hurt you, which are workaroundable, and which point to migration. Order an audit or book a free 15-minute call.
Related reading
- Is Base44 Production Ready? — the explicit decision framework using these limits.
- Base44 Vendor Lock-In Deep Dive — the SDK-and-schema lock-in mechanics.
- Base44 After the Wix Acquisition — what changed since June 2025, including which limits got worse.