Base44’s backend and database, explained for app owners

What “the backend” means on Base44

When you build on Base44 you never set up a server, but your app has one. It is a shared, managed service that every Base44 app talks to, and it does eight jobs:

1. Stores your data in a document database, organised as entities (tables).
2. Signs people in: registration, passwords, one-time codes, password resets, and social logins such as Google.
3. Enforces your security rules on every request, deciding who can see and change which records and fields.
4. Runs your backend functions, TypeScript code executed with Deno.
5. Runs automations and workflows on schedules and in response to data changes.
6. Provides built-in integrations: sending email, calling large language models, generating images, handling file uploads.
7. Holds connector tokens for services like Gmail, Google Calendar or Slack.
8. Pushes realtime updates to open pages when data changes.

Hosting sits alongside all of this. Base44’s external domain instructions point your DNS at base44.onrender.com, so published apps are served through Render.

How your data is stored: entities

Base44 describes each entity as a schema for documents in a collection, stored in a NoSQL database that is MongoDB-compatible, so apps can use MongoDB query operators through the SDK (Entities overview). In practice that means:

• Records are documents, not rows in a fixed table. A record can hold nested objects and lists, and the schema can change at any time without a migration. Base44 lists this schema flexibility as a feature.
• Every record carries built-in fields alongside yours, such as its ID, creation and update dates, and created_by, which holds the creator’s email address.
• Relationships are references. When an order belongs to a customer, the order stores the customer’s ID in a field. Nothing in the database enforces that the customer exists; your app’s code keeps them consistent.
• Deletion is soft at first. Deleted records are kept for 30 days and can be restored from Recently deleted, after which they are permanently removed (Managing your app data).

Security rules live next to the data

Each entity can carry row-level and field-level security rules (Entity security). Row-level rules decide who may create, read, update or delete a record; field-level rules decide who may read or write a particular field.

A rule is true (everyone), false (nobody) or a condition. Conditions compare the record with the person asking, for example “the record’s created_by equals the signed-in user’s email”, or check the user directly, for example “the user’s role is admin”. Rules can reference your own fields and custom user fields, and combine conditions with $or, $and and $nor.

Base44 enforces these on its server, per request, and it fails quietly on reads: a list or filter the rules deny comes back empty rather than raising an error, and a denied get returns “not found” whether or not the record exists. Denied creates and updates return a permission error. This behaviour is part of your app’s logic, whether you designed it that way or not, and any move to another backend has to reproduce it exactly or data will leak or vanish.

How your app talks to the backend

Every data operation in your pages goes through the Base44 SDK: list, filter, get, create, update, delete and subscribe on each entity; functions.invoke for backend functions; integrations.Core.* for the built-in integrations. Each call becomes an HTTP request to Base44’s API, authenticated as the signed-in user.

One limit shapes almost every data-heavy app: a single request returns at most 5,000 items, a rule Base44 introduced on 27 November 2025. The management API documentation adds that the response doesn’t tell you when it was cut short (Apps API: entities). A page that loads a whole collection simply stops at 5,000, so reports, exports and dashboards built on “fetch everything” quietly become wrong as the app grows. The fix is pagination.

Ways to get at your own data

What you won’t find is a database connection string. Base44 doesn’t document any way to connect a database client, a BI tool or a backup job directly to the database. Everything goes through the API.

The management API’s rate limits are counted per workspace, not per person, with a base allowance for Free and Starter that is multiplied by 2 on Builder, 3 on Pro, 5 on Elite and 10 on Enterprise (Rate limits). Listing and counting records share a base allowance of 70 requests a minute per app.

Backups and recovery

Base44 keeps deleted records for 30 days. Beyond that, automatic backups and data version history, where you can review, download and restore earlier versions of your data, are an Elite and Enterprise feature (Data version history). On other plans your backup strategy is whatever you export yourself, which in practice means CSV exports or a script against the API.

Users and sign-in

App users live in the Users section, with a role (admin or user, or a custom role) and any custom fields you add. Sign-in can use email and password, Google, Microsoft, Facebook or Apple, and single sign-on on the Elite plan (Managing login and registration).

Two details matter if you ever move:

• Passwords can’t be exported. Base44 doesn’t hand out password hashes, and its privacy documentation says app users can’t be exported at all.
• Google sign-in usually runs on Base44’s own OAuth client. The default setup shows base44.com on Google’s consent screen; a custom Google OAuth client, which shows your own domain, needs the Builder plan or higher.

Functions, automations and workflows

Backend functions are TypeScript running on Deno, available on the Builder plan and above, with a maximum run time of 5 minutes per invocation, whether called directly, by an automation or as a workflow step (Backend functions).

Apps created before July 2026 may use automations: a function on a schedule or triggered by data changes, where each run can last at most 3 minutes and runs can’t be closer than 5 minutes apart (Creating automations). Newer apps use workflows, which chain steps with conditions and delays. We cover those in migrating Base44 workflows.

Functions read their secrets, such as a Stripe key, from environment variables. The secrets’ names are visible in Base44’s dashboard and API; their values are write-only, which matters later if the functions have to run somewhere else.

What this means if you want to move

The backend is where Base44’s lock-in actually lives. Your frontend code is portable in principle; the backend’s behaviour is what your code depends on: document-shaped data with MongoDB-style queries, JSON security rules with Base44’s exact semantics, a sign-in service holding every password, and functions written against Base44’s SDK.

Moving to a relational database like Postgres means translating each of those, with a rewrite of the code that uses them. Moving to a backend that answers the same API on the same kind of database means none of it changes. That second approach is how Unbase44 works: your records go into your own MongoDB with their IDs intact, a documented Base44-compatible server enforces the same rules, and users keep their passwords.