A database you can use.Access you can understand.

A Fortly project can create its own PostgreSQL 16 database when you first use it. The server is shared, but the project’s database and owning login role are separate. You can work in the console, use the supported data APIs, and export the data instead of treating the database as a hidden implementation detail.

The Database workspace joins the everyday tasks: Objects for tables and other database objects, SQL Editor for queries and schema changes, Relationships for connected tables, and the table’s API tab for application-facing permissions, and Backups for point-in-time recovery and exports. The table you inspect is the same table whose access you review.

That is useful for a small app with one read-only project list and for a growing app with several related tables. Start by choosing the shape of your data, its keys and its relationships. Decide separately which operations should be available to the application, and under which identity.

Fortly sends your SQL to PostgreSQL. You can create schemas, tables, types, functions, views, triggers and indexes within your database. Your owner role is not a superuser and cannot administer the shared server or create other databases and roles. Extension availability depends on what is installed and trusted on that server.

create table public.projects (
  id bigint generated by default as identity primary key,
  name text not null,
  status text not null default 'Planned',
  created_at timestamptz not null default now()
);

insert into public.projects (name) values ('Customer portal');

This is a starting schema, not an automatic migration. Review it in SQL Editor before executing it in your own project. For relationships, use actual foreign keys so the structure is enforced by PostgreSQL as well as shown in the diagram. A visual connection should describe a database constraint, not merely decorate two cards.

SQL can work with more objects than the table Data API exposes. The ordinary table APIs serve public-schema tables; other supported database objects are available through SQL and documented routine patterns. Check the PostgreSQL compatibility page when planning advanced features.

In Objects, select a table, open its API tab, and choose the identity whose permissions you are editing. Enable Read, Create, Update or Delete deliberately, then review and apply the change. Use Test request to inspect the endpoint’s response while the same table stays selected. API keys and app sign-in remain in the shared Data API settings.

A Public Read grant is suitable only for records you intend public visitors to read. For user-owned records, connect a trusted identity provider and use row rules that match verified user claims. A publishable key does not itself identify a person. Review privileged functions separately, including functions that execute with their owner’s authority.

New server-framework deployments run as Workers. With a provisioned project database they receive DATABASE_URL and can use supported PostgreSQL drivers, with connections opened inside the request. Use the native Worker guide before carrying over a global process connection pool. Scoped HTTPS Data API roles remain available for integrations.

The server data API can be called with an account API token held in a runtime variable. That token acts as the account and should not reach browser code. When a frontend needs only reviewed table operations, use the publishable Data API route instead. The server access guide and frontend access guide show the supported request forms.

Capacity and query limits still matter. Review the documented connection, statement, row and request limits for the path you use. A large data set needs query design, pagination and indexes; increasing storage alone does not make an unbounded browser read an appropriate API.

Every database is backed up continuously on every plan: each change is saved within about a minute, encrypted, in a different region, and kept for seven days. On Pro and Max, Backups → Point in time restores the database to any minute in that window in a few minutes, and Undo puts the previous data back. Through December 1, 2026 (UTC), Free plans can restore too, once per project in a rolling 24-hour window. An application release rollback is not a database restore.

Explore the recovery workflow and reviewed Undo. For a copy you hold yourself, or for longer than seven days, use Backups → Exports and automate exports to storage you control.

Full exports can target PostgreSQL SQL, Fortly SQL, MySQL-compatible SQL or JSON. Format compatibility matters: triggers and routines are represented differently, and a database that uses both may require migration files or manual reconstruction for a complete restore. Test that restoration process before you depend on it.

For one table, the console offers CSV export; for a query, download the returned result. These are useful for inspection, but they are not substitutes for a tested full-database recovery plan. Read the export and restore reference for format details and row-security preservation.

Storage is pooled across your account according to the published plan and capacity model. Start with a schema and a representative query, confirm the API identity, then estimate growth from the rows and files your app will actually keep. That makes a capacity decision more useful than choosing a database size before you know the workload.