Appearance
Connecting Your Database
SchemaStack writes to a PostgreSQL or MySQL database that you own. You connect it once, either when creating a workspace or later from Workspace → Database.
The fastest way is to paste the connection string your database provider gave you.
Paste a connection string
Every managed database provider hands you a string that already contains the host, port, database name and credentials. Paste it into the Paste a connection string field and SchemaStack fills in the fields below it.
postgresql://alice:s3cret@db.example.com:5432/appdb?sslmode=requireThat single line fills in the database type, host, port, database, username, password and SSL mode. Anything the string doesn't carry is left alone for you to complete.
Check before you save
The parsed values appear in the normal fields, so you can see exactly what was understood and correct it. Nothing is sent anywhere until you press Test connection or Save.
Accepted formats
Three shapes are recognised, because providers disagree about which to hand out.
Connection URI
The most common form, used by most managed Postgres and MySQL providers:
postgresql://user:password@host:5432/database?sslmode=require
postgres://user:password@host/database
mysql://user:password@host:3306/databasepostgres:// and postgresql:// are equivalent. If the port is missing, SchemaStack uses the default for the vendor — 5432 for PostgreSQL, 3306 for MySQL.
Characters that are special in a URL must be percent-encoded, which providers normally do for you. A password of p@ss/word appears in the string as p%40ss%2Fword, and SchemaStack decodes it back.
JDBC URL
A JDBC URL is the same thing with a jdbc: prefix, and often carries credentials as query parameters instead of in front of the host. Both are handled:
jdbc:postgresql://db.example.com:5432/appdb?user=alice&password=s3cretKeyword/value form
The libpq style that psql documents and some providers print:
host=db.example.com port=5432 dbname=appdb user=alice password=s3cret sslmode=requireQuoted values are supported, so a password containing spaces can be written password='a b c'.
What gets filled in
| Field | Comes from |
|---|---|
| Database Vendor | The scheme — postgresql/postgres or mysql |
| Host | The host portion, or host= |
| Port | The port, or the vendor default when absent |
| Database | The path after the host, or dbname= / database= |
| Username | Before the : in the credentials, or user= |
| Password | After the : in the credentials, or password= |
| SSL Mode | sslmode=, or MySQL's useSSL= / requireSSL= |
| Additional Parameters | Every other query parameter, preserved as-is |
Parameters SchemaStack doesn't recognise are never discarded — they are collected into Additional Parameters so driver-specific options like application_name survive.
SSL modes
sslmode in the connection string maps onto SchemaStack's SSL setting:
| In the string | In SchemaStack | Meaning |
|---|---|---|
disable | Disable | No encryption |
allow, prefer | Prefer | Encrypt when the server supports it |
require | Require | Encryption required, certificate not verified |
verify-ca | Verify CA | Certificate must be signed by a trusted CA |
verify-full | Verify Full | As above, and the hostname must match |
Most managed providers require SSL, so their strings usually end with ?sslmode=require.
Verify CA and Verify Full need a CA certificate, which no connection string carries — paste the PEM into the certificate field after connecting. The same applies to client certificates, client keys and the connection timeout: those are never read from a connection string.
Where to find your connection string
| Provider | Where to look |
|---|---|
| Neon | Project dashboard → Connection Details |
| Supabase | Project Settings → Database → Connection string |
| Railway | The Postgres service → Connect |
| Render | Database page → External Connection String |
| Amazon RDS | Build it from the endpoint, port and database name shown in the console |
| Self-hosted | Whatever you already put in your application's config |
If your provider offers both a pooled and a direct connection string, prefer the direct one. Connection poolers sometimes restrict the statements SchemaStack needs to inspect the schema and run migrations.
Credentials are encrypted
The username and password are encrypted before being stored, and the password is never returned by the API once saved — editing the connection later shows every other field but requires re-entering the password only if you want to change it.
No database yet?
You don't need one to start. Creating your first workspace offers a managed database option: SchemaStack provisions a PostgreSQL database preloaded with sample data, so you can look around before connecting anything of your own. See Getting Started.
Troubleshooting
"That doesn't look like a connection string." The text didn't match any of the three formats above. The most common cause is pasting a dashboard URL rather than the connection string, or a fragment that's missing the scheme. Fill the fields in by hand instead — the paste field is only a shortcut.
The port is wrong after pasting. A string without an explicit port gets the vendor default. If your provider listens elsewhere, correct the port field after pasting.
Connection test fails with an SSL error. Managed providers usually require SSL. Set SSL Mode to Require, or to Verify Full with the provider's CA certificate if you want the hostname checked.
Connection test times out. The database must be reachable from SchemaStack's servers. Databases behind a private network or a firewall that only allows specific source addresses need that allowance adding first.
See also: Database Compatibility for the feature and type support matrix.