Database (Advanced)

When you change a schema after the table has been provisioned, GenMB applies the diff: new columns added with their defaults, removed columns dropped, type changes applied where Postgres permits. The migration runs on save; the Database Browser reflects the new state immediately.

GenMB names every column in your PostgreSQL tables in camelCase (for example createdAt and updatedAt). This includes the created and updated timestamps GenMB adds for you when you do not define them yourself. You do not have to manage this by hand - describe the columns you want in chat and GenMB sets the names up consistently.

Some apps created before mid-2026 have older-style column names like created_at and updated_at instead of the camelCase form. You do not need to do anything: GenMB automatically maps the old names to the new ones when it reads your data, so existing apps keep working and you can refer to either name.

A common need is that each person only sees their own rows - their own orders, notes, or bookings, never someone else's. GenMB handles this in your app's backend logic today: it checks the signed-in user against each record's owner before returning it. If you want this, just ask in chat - for example, "only let each user see their own tasks" - and GenMB wires it up using your app's sign-in and, if you use them, your access roles.

If a schema gets stuck in a pending or failed state, GenMB recovers it automatically the next time your app reads or writes data - it re-runs the setup behind the scenes. In most cases the table is ready again within seconds without any action from you. If a schema stays stuck, reprovision it from the Schema panel, or ask in chat and we will sort it out.

See Database & Schema for the basic workflow.

FAQs