Database Connections

Tell the AI which database you want and it scaffolds the whole data layer — connection string, migration runner, models, and seed data — wired to your backend stack. You describe the data; CodeSky handles the plumbing.

Supported databases

• PostgreSQL — the default for Node and Python backends.
• MySQL / MariaDB — widely supported on shared hosting.
• SQL Server — the default for the .NET backend.
• MongoDB — for document-shaped workloads.
• SQLite — zero-config, great for small or embedded apps.

Example prompt

"Use PostgreSQL. Add a users table with name, email (unique),
 password_hash, role, and a foreign key from orders.user_id."

You get a migration file in database/migrations/, a connection-string template in .env.example, an ORM model, and a working API on top.

Dev now, your database later

1. In preview, the backend runs against a local database (or a mutable in-memory store) so it works immediately with no setup.
2. To go live, set one environment variable — DATABASE_URL (or the stack's equivalent) — to point at your own Postgres/MySQL/SQL Server.
3. Run the migrations so the schema matches. Ask: "add a script to run pending migrations."

Changing the schema safely

• Add or alter fields by prompt, and ask for a migration each time so production can update in order.
• Mention indexes when a table gets big — "index orders by (user_id, created_at)".
• For data you can't lose, ask the AI to write a reversible migration.

Common mistakes to avoid

• Hard-coding credentials. Keep them in .env (git-ignored); the generator sets this up for you.
• Skipping migrations. Editing the schema without a migration leaves production out of sync.
• Choosing the wrong engine for the job. Documents → MongoDB; relational data with joins → Postgres/MySQL/SQL Server.

FAQ