Database engines
The databases a connection can point at, what each one supports, and how clients log in through relay connect.
A connection has one engine. The agent speaks that
database's own wire protocol, so your usual client works through
relay connect.
| Engine | engine value | Default port |
|---|---|---|
| PostgreSQL | postgres | 5432 |
| MySQL | mysql | 3306 |
| MongoDB | mongodb | 27017 |
| SQL Server | sqlserver | 1433 |
| Oracle | oracle | 1521 |
| Valkey and Redis | valkey | 6379 |
Availability
The dashboard's engine picker shows PostgreSQL, plus Valkey / Redis, SQL
Server and Oracle in organizations where each is enabled (the valkey,
sqlserver and oracle feature flags). The server also refuses SQL Server
and Oracle connections without their flag. MySQL and MongoDB
connections are created with the CLI or Terraform.
In the Agent Edition:
- The license decides which engines you can use. PostgreSQL is always
included; the others need the
mysql,mongodb,valkey,sqlserverororaclelicense feature. - Turn the flags on with
FEATURE_FLAGS_OVERRIDEon the server, for exampleFEATURE_FLAGS_OVERRIDE=sqlserver=on,oracle=on. Addvalkey=onto show Valkey / Redis in the dashboard's engine picker.
What each engine supports
| Masking | Policies and risk scoring | Query approvals | Runbooks | |
|---|---|---|---|---|
| PostgreSQL | Yes | Yes | Yes | Yes |
| MySQL | Yes | Yes | Yes | Yes |
| MongoDB | Yes | Yes | Yes | Yes |
| SQL Server | Yes | Yes | Yes | Yes |
| Valkey and Redis | Yes | Yes | Yes | No |
| Oracle | Yes | No | No | No |
This table describes the current state. Engines are getting more support over time, and the page for each feature lists what it covers.
How clients log in
The client never sends the database password. The agent logs in to the
database with the connection's user and credential, so whatever the client
sends as a password is ignored or checked against a fixed value. relay connect
prints the command to use for each engine:
| Engine | Client command |
|---|---|
| PostgreSQL | psql "postgresql://127.0.0.1:<port>" |
| MySQL | mysql -h 127.0.0.1 -P <port> |
| MongoDB | mongosh "mongodb://127.0.0.1:<port>" |
| SQL Server | sqlcmd -S 127.0.0.1,<port> -U noop -P noop -C |
| Oracle | sqlplus noop/noop@//127.0.0.1:<port>/<service> |
| Valkey and Redis | valkey-cli -h 127.0.0.1 -p <port>, or redis://127.0.0.1:<port> |
SQL Server
Any login and password work: the agent replaces them with the connection's
user and credential. The agent presents a self-signed certificate to the client
unless the connection has its own TLS certificate, so the client must trust the
server certificate (-C in sqlcmd, TrustServerCertificate=true in a
connection string) or turn encryption off. Windows, Kerberos and Azure AD
logins are not used: the agent always logs in with SQL authentication.
Oracle
Any username works, and the password must be noop. The agent checks that
password and then logs in to the database with the connection's credentials.
The connection's Database is the service name.
Valkey and Redis
One engine covers Valkey and Redis-compatible servers (Redis OSS, ElastiCache,
MemoryDB), over RESP2 and RESP3. The client sends no AUTH: an AUTH from
the client is answered OK without reaching the server. The connection's
Database is a database number; leave it empty for database 0.
The agent works with a standalone server, a primary with replicas behind
Sentinel, or a cluster. Clients always see a single standalone server: in
cluster mode the agent routes each command to the node that owns its key, so
clients do not need cluster support and never see redirects. A command whose
keys belong to different hash slots still gets the cluster's CROSSSLOT error,
so keep related keys under one {hash tag}. Commands that
would reveal or change the deployment are refused with an error: replication,
cluster and Sentinel commands, MONITOR, DEBUG, MIGRATE, MODULE,
SHUTDOWN, the ACL commands that list or change users, and
CLIENT REPLY OFF|SKIP.
Query audit records each command with its keys, never
its values: SET k v is audited as SET k.