Isolation
Customer → Neon project → one PostgreSQL database per environment → one Data API worker per environment at the edge. Development is a copy-on-write branch of Production's database, business data included; only run history is cleared.
Architecture & data
Your own system of record under every screen.
Every environment runs on its own dedicated PostgreSQL database, hosted in the EU. In front of it, the Data API checks each caller's permissions, then enforces your business rules and writes the audit row inside the same transaction as the change. The rest of your stack connects through the same documented GraphQL and REST API.
30-day trial with Pro capabilities · no card required
- 1
- dedicated PostgreSQL database per environment, in a database project of your own
- 11
- rule types enforced inside the write transaction
- 22
- built-in PostgreSQL domain types, from money with currency to status and files
- GraphQL + REST
- Data API for every environment, with REST described in an OpenAPI 3.1 spec
How the platform is built
Four layers, with the Data API in front of your records.
People work in apps, portals, AI Builder and Desktop. Workflows, AI steps and integrations run in the workflow engine. Screens, portals, workflows and API keys all reach your records through each environment's Data API, where rules and the audit apply to every write. Role, row and field permissions apply to every caller except a workflow's own automation identity.
bondi / architecture Diagram
-
Experience
Where people work
Apps and dashboards
Role-specific screens
Portals
External users, on Pro
AI Builder
Builds and changes the system
Desktop
Windows workspace
-
Runtime
Where the work runs
Workflow engine
Durable runs, retries, transactions
AI layer
Workflow agents get no database tool
Integration layer
Typed actions, events, HTTP
Secrets store
Encrypted credentials
-
Data layer
How the data is reached
Data API
GraphQL · REST · OpenAPI 3.1
Permissions
Roles and screens; rows and fields on Pro
Rules
Enforced in the write
Audit
Same transaction as the change
-
Your databases
One database per environment, archive inside
Production
Dedicated PostgreSQL
Development
Branch of Production, data included, on Pro
Archive
Removed tables and columns, purge-protected 30 days
Architecture diagram drawn from Bondi's infrastructure and service code, September 2026.
Want to see this on your own process? Our team will walk through it with you.
Talk to our teamWhat it does
Records, rules and history in a database of your own.
-
Business types, not just columns
Money with its currency, status with its options, tags, rich text, managed files, email, phone and date ranges are among 22 built-in domain types. A column states what it holds, not just how it is stored.
-
Rules enforced where the data is written
Required, read-only, hidden and validated fields, allowed status transitions, blocked deletes, lookups and computed values run inside the Data API's write transaction. A screen, a portal, a workflow and an API call that write the same record meet the same rules.
-
History that commits with the change
A record change made through the Data API writes its audit row inside the same transaction, so a rolled-back change takes its audit row with it. Rows changed by a delete cascade are the exception. The row records who made the change and when; updates also keep each changed field's old and new value.
-
An API for every environment
Each environment serves GraphQL and REST under the caller's own permissions. The REST API is described by an OpenAPI 3.1 spec generated for the tables the caller can access, so an integration team builds against a contract that matches its access.
-
Your data, in plain SQLPro
On Pro, the organization owner exports any environment's tables, with their schema and data, as a standard PostgreSQL dump. Your records never depend on a proprietary format.
Your data model, as PostgreSQL tables
Your data model becomes PostgreSQL tables with typed columns, constraints and foreign keys, in a database that serves one environment of one customer. Nothing is flattened into a shared generic table.
studio_ops / public Diagram
clients
- name
- text
- account_manager
- user_id
- retainer_hours
- numeric
- status
- status
projects
- client_id
- → clients
- budget
- money_amount
- stage
- status
- due_date
- date
deliverables
- project_id
- → projects
- owner
- user_id
- approval_state
- status
- due_date
- date
time_entries
- project_id
- → projects
- logged_by
- user_id
- hours
- numeric
- billable
- boolean
approvals
- deliverable_id
- → deliverables
- decided_by
- → contacts
- decision
- status
- decided_at
- timestamptz
invoices
- client_id
- → clients
- period
- datetime_range
- amount
- money_amount
- issued_at
- date
- Relationship
- Business type
Under the hood
The mechanisms, in detail.
The mechanisms behind the page, for the architects and security reviewers evaluating it.
Read the technical documentationRule engine
setValue, readonly, hidden, required, validate, blockDelete, filterOptions, existsCheck, lookupCheck, transition and trackingRecord, enforced inside the Data API's write transaction.
Audit
Each insert, update, delete and restore made through the Data API writes a row to _system._data_audit in the same transaction, so a rollback discards both. The row carries the acting user, the time and a source (user, system or restore); updates also store each changed column's old and new value. Rows changed by a delete cascade or a cascade restore, and values recovered from the archive, are not written there, and a failed audit insert is reported in the service log without blocking the change. Record history is read through the Data API under the viewer's permissions.
Query limits
Read-only SQL runs in a read-only transaction with a 15-second statement timeout, restricted to 83 allowlisted functions and the caller's permissions.
Designed boundaries
Where it starts and where it stops.
-
Other systems reach the data through the Data API, under a scoped identity, rather than through a raw database connection.
-
A Development database is a working copy of Production, business data included, so limit who can open it.
How Development works -
Bondi runs the operation, not the ledger: accounting, tax and statutory reporting stay in your financial system, which workflows reach through its API with the HTTP step.
How Bondi reaches other systems
Availability
- Standard
- Dedicated database, business types, rules, audit and the Data API
- Pro
- Development environment, owner-level SQL export and Service Accounts
- Enterprise
- BI read replicas and infrastructure requirements by agreement
Questions buyers ask
Straight answers.
Can our BI tool connect to the database directly?
Not through a raw connection string. Use the Data API under a scoped identity, or have the organization owner take a SQL export on Pro. Read replicas for BI are available through an Enterprise agreement.
Can we choose where our data is hosted?
Not today. Every customer is hosted the same way: databases on Neon in AWS eu-central-1, the application API in Google Cloud europe-west3, the Data API, workflow engine, AI Builder and sign-in on Cloudflare Workers, and files in Cloudflare R2 with an Eastern Europe location hint. AI steps, AI Builder and Chat send the data they work on to the AI model providers listed as subprocessors in our DPA, which may process it outside the EU.
What does the SQL export include?
Your own tables, with their schema and data, as a standard PostgreSQL dump that the organization owner takes on Pro. Bondi's system schemas, including the data-change audit, and archived tables are not part of it.
Can we bring data from our existing system?
Yes. AI Builder can prepare reviewed record imports, and migrating an existing PostgreSQL system is a scoped project with our team.
How long is data-change history kept?
Data-change audit rows are stored in the environment's own database, beside the records they describe, and stay with that data. The plan-based audit window on the pricing page applies to security events in the admin console, not to record history.
Next step
Take the architecture through your IT review.
Bring the questions your architects and security team will ask about isolation, the data layer, the API and getting data out. We'll walk through each one with you against this diagram.