Base44 cannot do real-time features (no WebSockets, no Server-Sent Events), cannot enforce default per-row data isolation (entities are globally readable by default until you add ownership filters), cannot bulk-delete records server-side, cannot offer a contractual SLA below Enterprise, cannot provide service-account auth for cross-user reads, cannot ship strict CSP or HSTS headers without a CDN proxy in front, cannot guarantee email deliverability outside its shared sender pool, cannot server-render pages for visitors (search engines and AI crawlers get a prerendered version, visitors get client-side rendering), cannot store HIPAA-covered PHI under a BAA, and cannot execute database transactions across entities. Each of these is structural, not a missing feature waiting to ship — plan workarounds 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 has structural limits that the marketing copy and the AI agent will not warn you about. This article, written by the lead engineer at Base44Devs, lists every one we have hit in real client work, with the workarounds where they exist and the honest answer of "you cannot do this here" where they don't.
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 add real-time chat" or "let's just store medical records here" without checking what the platform actually supports.
Architecture limits
No WebSockets, no Server-Sent Events
The Deno backend functions run as request-response handlers. There is no persistent-connection primitive. Real-time features require polling or third-party services.
Workaround: Pusher, Ably, or Liveblocks from the frontend. These cost extra and add an operational dependency. Polling works for low-update-rate cases but breaks down past 1 update per second.
No service-account auth mode
Backend functions execute as the calling user. There is no documented "service role" identity that can read across users. Cross-user reads require building authorization logic in your function and granting admin-only roles.
Workaround: a "system" user account with admin role, used by scheduled jobs. Not great. Sufficient.
No multi-tenant isolation primitives
Base44 has no concept of a tenant or organization at the platform level. If you build multi-tenant SaaS, you implement tenant_id filtering yourself on every query. There is no automatic enforcement.
Workaround: discipline. ESLint rules. Audit every query.
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 (Base44 SEO docs, read 23 Sep 2026). The limits that remain are narrower: if a rendered version is not ready yet, crawlers get a fallback snapshot 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, the cause is usually configuration — 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. Since 16 April 2026, Elite and Enterprise workspaces can store app data in EU or UK clusters instead, for apps created after that date; media files uploaded to your app, account details and billing information stay in the US regardless (Base44 privacy and security docs, read 23 Sep 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
Cold start latency is 200–800ms typical, more for functions with heavy imports. There is no warm-pool option.
Workaround: a synthetic monitor that pings each critical function every 60 seconds, keeping it warm at the cost of credits.
Data layer limits
No server-side bulk delete
There is no bulkDelete() method. Deleting 10,000 records means 10,000 API calls. This is documented as a production blocker by multiple teams.
Workaround: a backend function that loops delete() calls. Slow. Credit-expensive. Eventually finishes.
Default-permissive entities
Entity.list() with no filter returns every record. This is the source of most data-leak incidents we audit. Discussed in detail in the SDK reference and security checklist.
Workaround: ESLint rule, plus discipline, plus second-account testing.
Opaque storage caps
Base44 does not publish total database size or per-entity record limits. Apps have hit invisible caps and received unhelpful error messages.
Workaround: monitor entity record counts. If you cross 500K on any entity, plan for migration.
5,000-record-per-request limit
Since November 2025, list() caps at 5,000 records per call. This means listing a large entity requires pagination logic.
Workaround: paginate with cursor. Standard practice for any database, just be aware of the explicit cap.
Limited query operators
The filter API supports equality, $in, $ne, $gt/$lt/$gte/$lte, $or, $and. Missing: text search, geo queries, fuzzy match, regex.
Workaround: full-text search via a third-party service (Meilisearch, Algolia). Geo via a backend function with custom logic.
No transactions across entities
You cannot atomically update two entities. If a multi-entity update fails partway, you are in an inconsistent state.
Workaround: design schemas to avoid the need for cross-entity transactions. Idempotent operations. Compensating writes on failure.
No native database-level audit log
Changes to entity records are not automatically logged in a queryable form.
Workaround: a backend function that writes to an AuditLog entity on every mutation. Discipline-driven.
Limited indexing controls
You cannot define composite indexes, partial indexes, or full-text indexes. The platform makes indexing decisions internally.
Workaround: query patterns that align with whatever the platform indexes. For complex query needs, mirror data to a real database.
Authentication and identity limits
No fine-grained permissions
Base44 has admin/user as platform roles. Anything more granular (read-only, billing-admin, content-moderator) you build on the user entity.
Workaround: role field on user, gated checks in backend functions.
App SSO is OIDC-only and needs the Elite plan
Google OAuth and email/password are first-class. Single sign-on through an OIDC identity provider — Google, Microsoft, GitHub, Okta, Apple, or a custom IdP — is available for Base44 apps on the Elite plan or higher (Base44 SSO docs, read 23 Sep 2026). The docs describe OIDC only, so an enterprise customer whose identity provider speaks SAML alone has no documented path.
Workaround: below Elite, or for a SAML-only identity provider, route through Auth0 or Clerk via a backend function. Adds cost and complexity.
JWT in local storage
Tokens are accessible to any in-page script. Not configurable.
Workaround: minimize what the token can do, shorten TTL, sanitize all rendered content. Cannot fully eliminate the risk.
No MFA enforcement at the role level
You can require MFA per user, but not "all admins must have MFA enabled" as a policy.
Workaround: scheduled function that audits users and disables admin role for accounts without MFA.
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 23 Sep 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.
Webhook deliverability tied to active users
Multiple users have reported webhooks only firing when users are actively using the app. This breaks subscription renewals and other time-driven flows.
Workaround: external scheduler (cron-job.org, GitHub Actions) that triggers a backend function on a schedule.
Email deliverability shared across tenants
The platform's sendEmail uses a shared sender pool. Spammy neighbors hurt your deliverability.
Workaround: Resend or Postmark with your own domain and SPF/DKIM/DMARC.
Stripe in-app purchase not supported
For iOS apps wrapping a Base44 web view, Apple requires StoreKit for digital purchases. The platform does not support this.
Workaround: native shell around the web view that handles StoreKit. Complex.
Limited OAuth flows
Standard OAuth code flow works. PKCE without a backend, device flow, and complex multi-step OAuth flows do not have first-class support.
Workaround: build the flow yourself in a backend function.
Performance limits
No HTTP/2 push or HTTP/3 controls
Header configuration and protocol selection are not exposed.
Workaround: CDN in front.
No native CDN tier control
Asset caching headers are platform-default. You cannot specify long-lived caching for fingerprinted assets.
Workaround: CDN in front.
Credit cost scales with load
Every backend function call counts against credits. High-traffic endpoints can burn the monthly allowance in days.
Workaround: cache aggressively at the edge. Pre-compute results in entities.
Security limits
No native WAF
Base44 does not include a Web Application Firewall. SQL injection (against the SDK), bot abuse, and DDoS protection are your problem.
Workaround: Cloudflare WAF in front of your domain.
No log retention beyond platform default
Logs roll quickly. Forensic investigation after an incident requires logs you've shipped externally.
Workaround: ship logs out via fetch from every function.
Secrets are platform-managed, not a vault you administer
Base44 states it encrypts app secrets and manages them in a cloud key management service (KMS) (base44.com/security, read 23 Sep 2026); backend functions read them as environment variables. What the platform does not give you is a vault you administer yourself, which some customer security reviews ask for.
Workaround: a vault (1Password Connect, Doppler) accessed from a backend function at request time.
No admin-action audit log below Enterprise
Below Enterprise, who logged in when, who changed what entity schema, and who pushed which deploy are not natively logged. Enterprise workspaces get audit logs covering sign-ins, publishing and governance events, streamable through an Audit Logs API (base44.com/security, read 23 Sep 2026).
Workaround: below Enterprise, roll your own AuditLog entity, populated from backend functions.
Compliance and operational limits
No SLA below Enterprise
Base44 publishes no uptime SLA for self-serve plans; Enterprise customers get SLA commitments in their contract (base44.com/security, read 23 Sep 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 23 Sep 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.
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 HIPAA BAA
Base44 does not offer a Business Associate Agreement.
Workaround: cannot store PHI on the platform. For healthcare apps, the data layer must move off-platform.
Limited support response time
Customer support has been reported as slow or non-responsive on G2 and Trustpilot reviews. Quote: "Support ticket opened March 29 never received a single reply."
Workaround: do not depend on platform support for incident resolution. Build your own runbook.
Compliance and exit limits
GitHub sync needs the Builder plan
Base44's two-way GitHub sync requires the Builder plan or higher (Base44 GitHub docs, read 23 Sep 2026).
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" gives you the React app, but it still calls @base44/sdk against base44.com. Running independently requires re-implementing every SDK call.
Workaround: see vendor lock-in deep dive. Migration is engineering work, not a config change.
Database migration path is unclear
The platform has not published a documented "export your database" procedure that produces a portable schema and data dump.
Workaround: a backend function that calls Entity.list() for every entity and writes JSONL to external storage. 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 (Base44 GitHub docs, read 23 Sep 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 tolerate most of these gaps where customer-facing SaaS does not.
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 real-time low-latency features.
- You are storing PHI, large volumes of PCI data, or other regulated information.
- 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 the AI agent on architecture. The agent will happily generate WebSocket-based chat code that does not run on the platform. Verify against the platform's actual capabilities.
Assuming missing features will ship soon. Base44's roadmap is opaque. Some long-asked features (rollover credits, true bulk delete, granular permissions) have been requested for over a year with no platform commitment. Plan as if they will not ship.
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 | No WebSockets, single region, client-side rendering for visitors |
| Data | Default-permissive, no bulk delete, no transactions |
| Auth | JWT in local storage, no fine-grained roles |
| Integrations | Custom integrations need an OpenAPI spec and Builder+, webhook firing tied to user activity |
| Performance | No HTTP caching control, cold starts |
| Security | No WAF, no native CSP/HSTS, no audit log below Enterprise |
| Compliance | No SLA below Enterprise, SOC 2 covers the platform only (not your app), no HIPAA BAA |
| Exit | SDK lock-in, GitHub sync on Builder+ only |
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.