Database security and limits

Every Database request names a site, an app, a table, a caller, and an action. TaruviBase uses all five to find the data and decide whether the caller can access it.

Scope every request

A record request carries:

1. the site selected by the request hostname;
2. the app selected by app_slug;
3. the table selected by its logical name;
4. the caller selected by the credential; and
5. the record action: read, create, update, or delete.

A table name, record ID, or foreign-key value locates a resource. Access is granted separately through the caller's policy.

Create and change tables in TaruviBase Console with an administrator account, not from end-user applications.

Authenticate with one credential

Database requests support these credential forms:

Authorization: Api-Key <api-key>
Authorization: Bearer <jwt-access-token>
X-Session-Token: <headless-session-token>

For SDK and REST clients:

• use one credential mode per request;
• keep server-side API keys in environment variables or a secret manager;
• keep browser session tokens in the application's authenticated session storage and out of application source;
• use separate credentials for development, staging, and production;
• rotate a credential when its owner or purpose changes; and
• keep credentials out of URLs, logs, screenshots, examples, and source control.

401 Unauthorized means a supplied credential was not accepted. 403 Forbidden means you are signed in but your access policy denies the action. A route can use 404 Not Found for a denied record when revealing whether that record exists would disclose protected information.

Database record access requires an authenticated caller with an app role. Missing, invalid, or expired credentials do not provide record access. To make data public, serve it from your own endpoint that calls TaruviBase with a server-side API key limited to that data.

Apply least privilege

Design policies around the operation and data each caller needs:

• separate schema administration from record access;
• give reporting and support tools read-only access;
• use a dedicated identity for each server integration;
• verify one expected allow and one expected deny for every action;
• verify row scope with records owned by different users or teams; and
• evaluate access to the root record independently from knowledge of a foreign-key value.

Start with Authentication and authorization for roles, policies, and credentials.

Use the Database access-policy test guide to verify allow, deny, anonymous, cross-app, and cross-site cases before a release.

Verify the table policy

Every table needs explicit rules for the app roles and actions that can read or change its records. Before connecting application traffic:

1. Replace any initial fallback rule with the reviewed table policy.
2. Test one allowed and one denied identity for each action the application uses.
3. Repeat the checks from another app and another site.
4. Record the policy revision with the application release.

Use Test Database access policies for the complete matrix.

Separate administration from application traffic

Create, change, and delete tables in TaruviBase Console, and use it to inspect a table's definition and records. Keep administrative credentials separate from the identities used by an application to read and write records.

Use a compatible schema

For new application tables:

• use the generated UUID primary key named id;
• supply a UUID only when the application needs stable client-side identity;
• declare optional fields without required: true;
• create a referenced table before adding a foreign key to it; and
• select each foreign key's onDelete behavior deliberately.

Review the Schema reference before the table is provisioned so its field types, primary key, and foreign keys match the application's data model.

Bound every query

Make list behavior explicit:

• send page and page_size together;
• add stable ordering, such as title,id, when walking through pages;
• request only the fields the application uses;
• start with one filter and add conditions incrementally; and
• check that the caller can read every related table you filter, sort, or populate by.

The supported pagination grammar is page plus page_size. limit and offset are not Database pagination parameters.

Always send page_size so collection size is explicit.

Design predictable requests

Set page and batch sizes explicitly instead of relying on the default of 20 records per page. A page can hold up to 1,000 records, and a bulk request up to 1,000 records. The query examples use 20 records per page; choose the smallest page that supports the interface and split larger jobs into observable batches that can be read back and retried independently.

When the service returns a size or query-complexity validation error, keep the same scope and operation while reducing the page, batch, filter, or sort set. The feature guides describe the input requirements for search, relationships, and other advanced queries.

Limits complement authorization; they do not replace it. Treat a rejected filter, sort, or relationship expression as a failed request and never retry with a broader query.

If TaruviBase returns 429 Too Many Requests, wait for Retry-After when it is present and reduce concurrency before retrying.

Protect destructive changes

Deleting a record removes it from the table. Review the exact record IDs and their dependencies before sending a destructive request.

Use single-record deletion or an explicit bounded ID list. To delete records selected by a filter, query the set first, review its IDs, and submit those explicit IDs through the bulk workflow.

Before a destructive operation:

1. Confirm the site, app, and table.
2. Select the exact record IDs.
3. Review foreign-key dependencies and onDelete behavior.
4. Export the records you are about to change.
5. Use a credential that is allowed only the action you need.
6. Apply one controlled batch.
7. Verify the result with a read before continuing.

Share safe diagnostics

For troubleshooting, retain:

• HTTP status and structured error code;
• UTC timestamp;
• site hostname, app slug, logical table name, and operation; and
• a minimal redacted request shape.

Remove credentials, session cookies, personal data, customer records, and private configuration. Reproduce an issue with synthetic data whenever possible.

Continue with Troubleshoot Database for a symptom-to-resolution guide.

For interrupted writes, concurrent updates, schema rollback boundaries, and event delivery, continue with Database reliability.