Connecting to your Layerbase Cloud database

Every Layerbase Cloud database comes with a connection string, a hostname, and TLS. Any standard client for your engine works, the same one you would point at a local Postgres or Mongo.

Open your database in the dashboard

Go to /cloud, click the database you just created, and the connection panel shows the host, port, username, password, and a ready-to-paste connection string for the engine.

The dashboard always has the freshest credentials. If you ever rotate your password, the new value shows up there immediately.

TLS is required, on by default

All Layerbase Cloud connections are encrypted. For PostgreSQL, CockroachDB, SQLite, DuckDB, and QuestDB this means appending ?sslmode=require to the connection string. For MongoDB and FerretDB it means tls=true. MySQL and MariaDB clients usually just need the host plus a TLS flag.

HTTP-native engines (Qdrant, Meilisearch, InfluxDB, CouchDB, SurrealDB, Weaviate, libSQL) reach you over HTTPS on port 443. No flag needed, just a valid bearer token from the dashboard.

Use any standard client

psql, mysql, mongosh, redis-cli, ioredis, mongoose, drizzle, prisma, pg, mysql2, the official engine SDK, your ORM, your favorite IDE: they all work. Layerbase Cloud terminates connections at the engine's native wire protocol.

For serverless and edge runtimes, Redis-family databases also speak the Upstash REST API, and MySQL-family databases speak the PlanetScale serverless driver. Same database, alternate protocol, picked via the hostname suffix.

Engine-specific quirks

The in-dashboard connection panel has working examples for the most common client per engine, and the source-available SpinDB CLI docs cover the wire-level details if you want to dig deeper.

Which engines run on Cloud

Most of the engine grid is creatable on Layerbase Cloud. Two are Desktop and SpinDB only for now: CockroachDB and SurrealDB. They do not appear in the Cloud create flow, but you can run either one locally with the desktop app or the SpinDB CLI.

Selecting MongoDB provisions FerretDB, an open-source database that speaks the MongoDB wire protocol. You connect with the normal Mongo clients (mongosh, mongoose, the official driver) over a tls=true connection string. There is no licensed MongoDB server behind it.

TigerBeetle on Cloud is Alpha: it needs a Pro plan with at least one pool block, and IP allowlisting is enabled automatically because it has no built-in username or password. Every engine, including the Desktop-only ones, is available locally through SpinDB.

Pooled vs direct connections

PostgreSQL and the other Postgres-wire engines (CockroachDB, QuestDB, DuckDB, SQLite) plus the MySQL family (MySQL, MariaDB) sit behind a connection pooler. The pooler multiplexes many client connections onto a small set of real database connections, so a serverless or edge deployment that opens a fresh connection on every request does not exhaust the database's connection limit.

When a database has a pooler, the Connect dialog's Connection string tab shows a Pooled toggle. Leave it on (the default) for serverless functions, edge runtimes, and anything that makes many short-lived connections. Turn it off for the direct string, which connects straight to the database on its internal port.

If your app runs on a serverless platform (Vercel Functions, AWS Lambda, Cloud Run, Netlify Functions), use the pooled connection string. Beyond connection reuse, a database's direct port enforces a hard platform limit of 20 new connections per 10 seconds per source IP. Serverless fleets share a small pool of NAT egress addresses, so a traffic burst can push every instance's connection attempts through one IP, trip that limit, and surface as refused or reset connections that look like an outage. For the Postgres-wire engines the pooled string routes over the shared 5432 endpoint, which is not subject to that per-port cap, and PgBouncer reuses server connections behind it. MySQL and MariaDB have no shared endpoint, so their pooled string still uses a dedicated port: keep connection churn low there too.

Use direct for long-lived connections, admin sessions, and features the pooler cannot proxy, such as PostgreSQL LISTEN/NOTIFY, session-level settings, and some backup tools. Schema migrations are not on that list. The usual advice to switch to a direct string for migrations comes from poolers that break them; ours does not. Payload CMS and Drizzle migrations both run end to end through our transaction-mode pooling, so keep your migration runner on the same pooled string as the rest of the app. The pooled string omits the canonical default port (5432, 6379, 27017, 443) for readability; flip Show port in the same dialog if your client needs it spelled out. Edge runtimes that cannot open a raw socket at all should use the HTTP and serverless endpoints instead.

Per-engine connection guides

Create a database Open dashboard View billing