Menu
Platform
AI
App store purchases
Credits
Database
Flags
Generated Assets
Monitoring
Notifications
Organizations
Payments
- Payments
- Payments quickstart
- Checkout policies
- Checkout sessions
- Customer subscriptions
- Entitlement grants
- Exchange rates
- Licence keys
- Licence tokens
- Merchant accounts
- Portal sessions
- Price catalogs
- Revenue
- Revenue facts
- Revenue sources
- Tax threshold statuses
- Usage events
- Usage invoices
- Usage meter prices
- Usage meters
- Usage reservations
- Usage settings
- Usage tiers
Queues
Realtime
Sandboxes
Webhooks
Getting Started
Authentication
KV Store
Deploy & Infrastructure
Reference
Database
What a Sylphx database is, what you configure, and how it connects to your app.
Today this runs on the management API
Databases are provisioned with POST /v1/resources and bound to an environment, as in the Database quickstart. The databases collection serves reads at api.sylphx.com; its create, delete, restore and connect are not served.
A Database is one customer Postgres. It is not a schema on a shared server: a database has its own engine, its own credentials, its own backup, its own region, and its own deletion. Nothing you do to yours can be seen from anyone else's.
#What you choose, and what you do not
You choose the Postgres major version, the compute size, the region, and
whether deletion is protected. You do not choose an instance class, a disk
size, a replica count or max_connections: those derive from the compute size,
so a database cannot be configured into a state it cannot serve.
| Field | Type | What it is |
|---|---|---|
postgres_version | string | The Postgres major version, for example 17. The newest supported version is the default. |
compute_units | double | The compute size, in units. The default comes from the plan, and max_connections derives from it. |
region | string | Where the data lives; the project’s home region by default. Changing it moves the data by signed export and import. |
deletion_protection | bool | While set, Delete fails, and the database is kept. |
An idle free-tier database stops, and the next connection wakes it. That is a state you do not manage: nothing to start, nothing to shut down.
#Every database is addressable
A database's name is a path, and the same path works in the API, the CLI and the console:
- Name
- orgs/{org}/projects/{project}/envs/{env}/databases/{database}
- Id
- db_<location><ulid>
Read a database, list the ones in an environment, create, update, delete,
open a connection, rotate its credentials and restore it in place — the
databases collection has every call, with its scope
and its examples. data:read covers the reads; everything that changes the
database needs data:write.
#Postgres, with the extensions you would install yourself
pgvector is part of the engine, so a vector column is a normal column:
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE documents (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
content text NOT NULL,
embedding vector(1536)
);
CREATE INDEX ON documents USING hnsw (embedding vector_cosine_ops);#Backups and point-in-time restore
A database is backed up on its own schedule, and restore puts it back to a
point in time inside its retention window. The restore happens in place: the
database is unavailable while it restores, and everything written after the
restore point is gone.
A restore is destructive
restore is the one call that removes data on purpose, so the CLI asks before
it runs and the API takes validate_only. Backups and restore
has the procedure.
#Connections are issued, not constructed
There is no connection string in the console to copy into a repository: you
ask for one with connect, and it is returned to that caller only. The
response carries the pooled uri and — for Postgres — the direct_uri that
migrations, pg_dump, LISTEN/NOTIFY, session SET and logical
replication need.