Databases

Overview

A project's databases are dedicated PostgreSQL clusters running on Cosmoner's own hardware. You pick a version and a size, and pay a fixed monthly price for that capacity — there is no allowance to run out of and nothing metered on top.

Patching is handled for you, and every cluster hands you a connection string when it finishes provisioning.

Always-on

A database is a dedicated PostgreSQL cluster sized by you. There is no sleeping, no allowance and no usage cap: you are buying capacity, and the monthly price is the same whether you use it or not.

You choose:

• Version — the PostgreSQL major version. It is fixed for the life of the cluster, so pick the one your application and its extensions are ready for.
• Size — vCPU, memory and disk. The disk is part of the plan and is included in its price; there is no separate storage line.

Every cluster is a single node, runs in Cosmoner's own data centre in Stockholm, and is reachable from the apps in the same project. Storage is persistent and survives restarts and maintenance.

Choosing a size

Size from the working set rather than the total data: PostgreSQL is fastest when the rows you query often fit in memory. The smallest size is meant for development, staging and side projects, and halves max_connections to 50 — put a pooler in front of it if your framework opens more.

Move up a size when queries start reaching the disk rather than the cache, or when the data outgrows the disk the size includes.

Changing size

Every size is listed on the cluster's detail page next to your current one, with what changes shown before anything is charged. A change applies prorated against your billing period.

A size whose disk is smaller than the data the database already holds cannot be selected. Free up space first.

Connecting

When provisioning finishes, you are shown the host, database name, user, password and a ready-made connection string. The password is shown once — copy it into your secret manager or your app's environment before leaving the page. See the Secrets guide for storing it.

If you lose it, rotate the password from the database's detail page and update whatever was using the old one. Rotating invalidates the previous password immediately.

Browsing your data

Every database has a Data tab on its detail page, next to Overview. It is there for looking at what the database actually holds without installing a client.

The tab opens a console in two halves. On the left is the table list: the database it is connected to, a schema filter, a search box, and every table and view the database's user can read, with a rough row count against each one. That list stays where it is; the right-hand side switches between two views of whatever you pick.

• Grid — the table's rows, fifty at a time. Click a column heading to sort by it, step through pages from the toolbar, and add, edit or delete rows where the database allows it.
• SQL — an editor for running statements. Ctrl/Cmd + Enter runs what is in it, and clicking a table in the list writes its name into the query at the cursor instead of opening it. A query's results sort too, though only the rows that came back — sort the whole result with ORDER BY.

Rows can be selected. Tick the box at the left of a row, or the one in the heading to take the whole page; hold Shift while ticking to take everything between it and your last one. A bar above the rows then says how many are selected and what can be done with them: Copy as CSV puts them on the clipboard with a header line, and on a table you may write to, Delete removes all of them at once. The selection is cleared whenever the rows underneath it change — another table, another page, another sort.

Row counts, in the list and in the toolbar, are estimates from the database's own statistics rather than exact counts.

The console fills the tab, and when that is not enough room it goes full screen (Esc leaves it) or opens in a browser tab of its own. On a phone the table list starts out of the way; the button at the left of the toolbar brings it back.

Reading and writing

The console can also change data, for members with write access on the project.

Rows are editable in place. Add row opens a form with a field per column, Edit opens the same form filled in from the row, and each row has a delete button behind a confirmation — as does a selection of several, which is removed in a single transaction, so either every selected row goes or none of them do. Columns you leave untouched keep their value — or take the column default, when adding a row — so you can change one field without restating the rest. Nullable columns have a Set to null box, since an empty string and a null are different values.

Editing requires a way to name one row rather than every row that looks like it, which means a primary key, and a table rather than a view. Tables without one remain browsable; the console says so and points you at the SQL view, where you write the WHERE clause yourself.

The SQL view runs statements that write. You can send several separated by semicolons, and they all run inside one transaction — if any statement fails, none of them are applied. Each statement reports what it did: rows returned for a read, rows affected for a write. A few statements that act on the database server rather than on your data are refused; run those with your own client.

Members without write access see the tables and a read-only SQL view, and no edit controls.

Limits

Two limits keep panel activity from disrupting the application using the same database: a statement is stopped if it runs longer than a few seconds, and a write waiting on a lock gives up quickly rather than holding on. Only the first rows of a large result are returned. Add a LIMIT and a WHERE clause to work within all three.

Doing this over the API

A database can be created, resized and deleted over the API with a key that has databases: read, write scope — see the API Keys guide for issuing one. The endpoints are in the OpenAPI document, which is generated from the same schemas the API validates against.

Related: shared databases

Shared databases are a separate product from the above. They exist for handing isolated, pooled databases on one shared PostgreSQL cluster to your own end-clients, rather than for running your own app's data. See the Shared Databases reference.