Deployment

Databases: Supabase and Render Postgres

Understand where your product's data lives, what it costs, and how to back it up and export it.

If your product remembers anything — bookings, users, listings, submissions — it has a database. Idea to Life projects use one of two Postgres options: Supabase (the default for most products) or a Render Postgres instance. Both live in accounts you own; your data is never stored in an Idea to Life database.

Supabase (the usual choice)

Supabase is Postgres plus batteries: user authentication, file storage, auto-generated APIs, and Row Level Security (RLS). The platform defaults to it whenever a product has user accounts or benefits from those extras. The blueprint defines your tables; the build creates them in your Supabase project along with RLS policies so that, for example, customers can only read their own bookings.

Cost honesty: Supabase's free tier is real and useful, but free projects pause after prolonged inactivity — your product will error until you resume the project in the Supabase dashboard. For customer-facing products, budget for Supabase's paid tier. See the Supabase Setup guide for connecting keys and the critical distinction between browser-safe and server-only credentials.

Render Postgres

Some blueprints use a plain Render Postgres database instead — typically products that need a database but none of Supabase's auth or storage features. It lives in your Render workspace alongside your web service, connected via a DATABASE_URL environment variable.

Cost honesty: Render Postgres is a paid resource after a short trial. If your blueprint includes one, the estimate will say so; expect a monthly Render charge. This is one of the clearest cases where "deployment is free" would be a false promise, so we do not make it.

Migrations: how schema changes happen

When a change request alters the data model ("add a phone number field to bookings"), the platform writes a migration — a script that alters tables safely without losing existing rows — commits it to your repository, and applies it during deployment. Migrations live in your repo, so the full history of your schema is versioned alongside your code.

Backups

Supabase runs daily backups on paid plans; free-tier projects should not be trusted with data you cannot afford to lose.
Render Postgres includes automated backups, with retention depending on plan.
Independently of either, you can export at any time: your schema is in your repository, and a standard `pg_dump` against your DATABASE_URL produces a complete portable copy of the data.

Before requesting a risky data-model change on a product with real customer data, take a manual backup. It costs a minute and removes the worst case.

Looking at your data

You do not need SQL to see your data. Supabase has a spreadsheet-like table editor in its dashboard; Render Postgres can be browsed with any Postgres client. Read access to your own data never goes through Idea to Life.