How to connect
Use host, port, and credentials from the dashboard with TLS. Examples cover PostgreSQL; other engines use the same fields with their native clients.
Connection fields
After create or a password reset, the dashboard shows everything you need:
- Host: the hostname on the database detail page.
- Port: the port on the database detail page.
- Database / name: your database or Redis/Mongo target name from the page.
- Username: the database user shown on the page.
- Password: shown once after create or reset; keep it private.
- TLS/SSL: require.
Always use the host and port from your QubicDB dashboard. That is the supported path in production.
PostgreSQL URI
Most PostgreSQL apps accept a URI. Replace the placeholders with values from your dashboard:
PostgreSQL URI
postgresql://USER:PASSWORD@HOST:PORT/DB_NAME?sslmode=requireMariaDB, MongoDB, and Redis
Use the same host, port, user, and password from the dashboard with each engine’s usual client or driver. Enable TLS the way that client documents. Allowlist the public IP of the host that opens the connection.
Command line (psql)
psql
psql "postgresql://USER:PASSWORD@HOST:PORT/DB_NAME?sslmode=require"GUI clients and IDEs
Any client that supports TLS for your engine works (TablePlus, DBeaver, pgAdmin, mongosh/Compass, redis-cli with TLS, JetBrains tools, and similar). Enter host, port, database/name, user, and password from the dashboard, then require TLS.
- For PostgreSQL, use SSL mode require unless your team has a documented CA setup for verify-full.
- Connect to your QubicDB database name only. Do not open a default system database such as postgres unless the product tells you to.
- If a PostgreSQL client shows schemas, look under tenant as well as public. App migrations often create tables in tenant.
- Each open GUI session counts toward your connection limit together with your app.
Where PostgreSQL tables appear
New tables from many frameworks land in the tenant schema. In your client, open schema tenant if you do not see tables under public.
Connection limit
Each database user has a concurrent connection limit (often 5 on free shared profiles). Every open session from your app, pool, GUI, or IDE shares that same limit.
- DataGrid + your app each holding one session = 2 connections.
- An app pool of 5 leaves no room for a GUI until the pool shrinks or clients disconnect.
- On the database detail page, Connections is a sampled count (same cadence as storage), not a live meter.
If you hit the limit, close unused GUI tabs, lower the pool size, and wait for idle sessions to time out. There is no per-session kill control in the dashboard yet.