Database

Almost every app has to remember things between visits: who ordered what, which tasks are done, what a user wrote. That is the database. On Backenly you do not write the server code that usually sits in front of it. Your agent creates the tables, Backenly serves them as an API, and the access rules run inside PostgreSQL, so a filter forgotten on one screen cannot show one user another user’s data.

1. 1

   Your agent asks for the change

   With ordinary PostgreSQL DDL through apply_migration, or by describing the tables to backend_chat. Either way Backenly turns the request into typed actions rather than running raw SQL, and refuses anything it cannot map.

2. 2

   Backenly applies the checked steps

   Tables are created in your project’s own PostgreSQL schema, with a schema snapshot before a change. A multi-statement migration is checked before any step runs; if execution fails, it stops and reports what applied and what remains, so your agent can finish without replaying completed work.

3. 3

   Every table gets an API

   /api/v1/{projectId}/db/{table} lists, creates, reads, updates and deletes rows, with filters, sorting and pagination. There is no generate step and nothing to keep in sync.

4. 4

   The rules run in the database

   Row-level security policies read the signed-in user from each request, so the same rule holds through the REST API and the SDK. After a build, Backenly signs in a second test user and checks they cannot read the first user’s rows.

Once your coding agent is connected, ask it:

Create a tasks table with a title, a status of todo, in_progress or done, and a due date. Each user can only see and edit their own tasks.

Add a comments table. Each task has many comments, and each comment belongs to the user who wrote it.

import { createClient } from '@backenly/sdk'

const backend = createClient({ projectId, apiKey })

const open = await backend.tasks.list({ where: { status: 'todo' }, limit: 25 })
await backend.tasks.create({ title: 'Ship onboarding', status: 'todo' })

• A request without a signed-in user’s token reads zero rows from a protected table instead of failing. If a list is unexpectedly empty, check the X-User-Token header before the data.
• Every table Backenly creates gets id, "createdAt", "updatedAt" and deleted_at. Rows with a deleted_at time are left out of API reads unless the request asks for include_deleted=true.
• Dropping a table or a column never runs straight from your agent. It waits in the Autonomy review queue until a person approves it.
• There is no rpc() endpoint for SQL functions. Server-side logic runs as a Function.