Each project gets one Postgres. Create tables, query them, and filter rows by who signed in, all here.
One Postgres per project.
Create tables, run SQL and filter rows by who signed in, all here. The login identity is the row filter, so you do not write a separate permission layer.
Link a project and you can create tables: click in the console, or run one CLI command. Both do the same thing.
Call REST or SQL from your server with the project key. Schemas, rows and query results are all visible in the console.
Business tables store user_id (the sub of the Auth JWT). Row-level access filters on it, so you do not write a separate permission layer.
Business tables store a user_id column (the sub of the Auth JWT). Queries filter on it automatically. In the same table, user_a on the left only sees their own rows. Access follows identity, so you do not hand-write it.
Stand up another database, write the connection string yourself, hand-map external account ids into tables, then wire access and backups yourself.
One Postgres per project. The login identity becomes the row filter. Tables, SQL and vectors live in the same project.
npx @vectoree/cli db create --name todos --columns "…"
npx @vectoree/cli db query todos --limit 20
Can I bring existing tables in?
Yes. Existing tables can be imported. Inspect and change the structure in the console, and export rows when you need them.
How does row-level access decide?
By the authenticated user. Business tables store user_id (the sub of the Auth JWT). Row-level access filters on it, so permission checks do not have to be written in application code.
If I run SQL in the browser, does dropping a table happen immediately?
No. Dropping a table asks for confirmation first.
Where are functions and triggers managed?
In the console. The logic lives with the data, and does not depend on one deploy succeeding. Indexes and triggers can be inspected in the same place.