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. Just ask in chat - for example, "only let each user see their own tasks" - and GenMB writes your app so it tags each record with its owner and filters every read by the signed-in user, using your app's sign-in and, if you use them, your access roles. This scoping lives in your app's own code, so keep it in place if you edit those queries by hand.

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