Each SaaS application has separate core, AI, and logs databases. Customer organizations within that app share its databases; server-enforced account, DataRole, Location, and record permissions protect their data.
App identity binds the three SaaS databases to the correct product. Custom services require a separately provisioned compute environment. Shared platform services and host capacity remain outside the per-app database boundary.
Records, fields, pages, users, roles, workflows, conversations, calendar, and billing state for that application.
A separate append-only store for access logs and audit events. The application writes to it and cannot rewrite it.
Embeddings, chunks, retrieval logs, and installed harness packs, kept apart from the transactional workload.
Runs declared custom endpoints once the operator provisions and verifies the service environment. Firecracker and GPU infrastructure are still pending in the current launch environment.
Each database carries the identity of the application it belongs to. If a connection string ever pointed the wrong application at the wrong database, the mismatch is caught rather than quietly serving someone else's data.
Separating the compliance store from the runtime is what makes the audit trail worth having. An audit log the application can edit is a diary, not evidence.
Embedding and retrieval work is heavy and bursty. Keeping it on its own database means an AI query storm doesn't degrade someone entering an invoice.
This is the difference between a tool you outgrow and a platform you keep.
Every low-code platform has a ceiling. The question is what happens when you reach it. On most, the answer is a proprietary scripting language, a support ticket, or a migration.
Here, the answer is that your developer writes ordinary code. A custom service is packaged, installed into the application's own container, and declares the endpoints it exposes with their input and output schemas. From then on, your pages, workflows, scheduled jobs, and AI actions call it like any other endpoint.
Bringing in an outside contractor does not mean widening your security boundary. The extension runs inside a declared contract, and the platform decides what it is allowed to touch.
Extension packages carry a publisher, a semantic version, an image digest, a manifest, a release fingerprint, a signature, and an SBOM reference. You always know exactly which build is running, and a bad release can be revoked rather than chased.
Your application's databases are dedicated to that application and are not shared with other customers of the platform. A partner deployment option exists for organizations that require the runtime to sit on their own hardware.
Yes. Exports include your records, files, AI data and vectors, and log history, packaged with a manifest and SHA-256 checksums.
Whatever your developer prefers, as long as the service can expose the endpoints declared in its manifest. There is no proprietary scripting language to learn.
Create an account, explore the full builder console, and launch your first application on a custom domain. Nothing is charged while your application is still in development.
No credit card required. The console preview, the documentation, and the architecture reference are all readable before you sign up.
Get started free Read the docsAn app has routed Core, Logs and AI database planes. Provisioning is a staged operation: wait for readiness and any reported setup requirements before inviting customers. Marketplace presentation installs are pinned snapshots; upgrading a template is explicit. Customer-hosted Appliance operation and optional extension compute have their own deployment requirements.
Read the guideConfigure connections and credentials for the intended app and organization, verify the connection, then explicitly enable the supported workflow or schedule. Mail delivery, payment processing, Snowflake export and background jobs depend on their configured providers and workers. A queued receipt is not delivery, bank settlement or completed execution.
Read the guide