Shared or dedicated Postgres?
A shared database is a tenant on a pooled Postgres instance: quick to create and suited to development and small apps, with self-serve daily backups and restores once you turn backups on. A dedicated database has its own instance, CPU, memory and disk, and is always backed up continuously. Every database starts with 10 GiB of storage; the tier sets how far it can grow.
The engine, version, isolation and region are fixed when you create the database; tier, storage and pooling can change later. PostgreSQL 14, 15 and 16 are available.
A database’s storage counts toward your plan: 10 GiB on Starter, 20 GiB on Standard, 50 GiB on Pro and 150 GiB on Scale, plus any extra storage you buy. On Starter, one shared database reserves all 10 GiB.
| Tier | Isolation | Storage ceiling | Backups and restore |
|---|---|---|---|
| starter | Shared by default | 10 GiB | Daily dump when you turn it on; you restore it yourself |
| standard | Dedicated | 20 GiB | Always on: weekly base backup plus continuous WAL archiving; restore by Codara on request |
| pro | Dedicated | 100 GiB | Same as standard |
How do you create the database and connect it?
In the console, open the environment’s canvas, add a database and connect it to the app. From the CLI, create it in the same workspace, project and environment as the app, then add the connection. Connecting injects the variables and restarts the app.
codaracloud databases create main-db --engine postgres --tier starter \
--client my-workspace --project shop --env production
codaracloud apps connections add api main-db --client my-workspace
codaracloud apps connections list api --client my-workspaceTo connect a second database, such as a cache, give it a prefix with --as CACHE; its keys then start with CACHE_.
| Variable | Use it for |
|---|---|
| DATABASE_URL | Your application’s queries. On shared Postgres it goes through a connection pooler. |
| DATABASE_DIRECT_URL | Migrations and tools that need a direct connection. |
| DATABASE_HOST, _PORT, _NAME, _USER, _PASSWORD | Libraries that want the parts separately. |
How does your code use it?
Read DATABASE_URL from the environment; never hard-code the credentials. Point your migration tool (Prisma, Drizzle, Alembic, Django and others) at DATABASE_DIRECT_URL, which bypasses the pooler.
import pg from "pg";
const pool = new pg.Pool({ connectionString: process.env.DATABASE_URL });
const { rows } = await pool.query("select version()");import os
import psycopg
with psycopg.connect(os.environ["DATABASE_URL"]) as conn:
print(conn.execute("select version()").fetchone())Run migrations as the app’s pre-deploy command, for example npx prisma migrate deploy, alembic upgrade head or python manage.py migrate. It runs once in the new image before traffic moves, and if it fails, the current release keeps serving.
How do you import existing data or inspect the database?
Open a local tunnel through the platform and use psql or your usual client; no cluster access is needed. That is also the simplest way to load a pg_dump from another host. For large dumps, Postgres and MariaDB databases can import a plain SQL dump from an HTTPS URL as a job inside the platform, through the API or the MCP tools; ask your coding agent to run databases_import.
# Export from the old host
pg_dump --no-owner --no-acl "$OLD_DATABASE_URL" > dump.sql
# Open a tunnel (Ctrl-C to stop)
codaracloud databases proxy main-db --client my-workspace --local-port 5433
# In another terminal: credentials, then the import
codaracloud databases connection main-db --client my-workspace --reveal
psql "postgresql://USER:PASSWORD@127.0.0.1:5433/main-db" -f dump.sqlThe console also has a read-only table browser for Postgres (open the database and choose Studio). It pages through rows; it does not run SQL.
How do backups and restores work?
Check each database’s protection rather than assuming it. Shared Postgres takes a daily dump once you turn backups on, and you can restore it yourself. Dedicated Postgres is always backed up and cannot be turned off; Codara restores it on request. On self-serve plans, backups are kept for up to 7 days, stored with a separate provider.
A restore always creates a new database and never overwrites the source. Verify the restored data, then point the app at it. You can also take a backup before a risky change, once per database per UTC day.
codaracloud databases backup main-db --wait --client my-workspace
codaracloud databases restore main-db --from <backup-name> \
--as main-db-recovered --client my-workspace
codaracloud apps connections rm api main-db --client my-workspace
codaracloud apps connections add api main-db-recovered --client my-workspaceQuestions
- Is Postgres included in the Codara Cloud price?
- Yes. Databases run inside your plan’s capacity at no extra charge, and their storage counts toward the plan’s persistent storage. There is no separate database bill.
- Can I use an external database such as Neon or Supabase instead?
- Yes. Set its connection URL as a runtime environment variable on the app. The external provider bills and backs it up on its own terms.
- Which other databases are available?
- MySQL, MariaDB, Redis and MongoDB are also managed. Redis can be shared or dedicated; MySQL, MariaDB and MongoDB are dedicated only.