¶Configuration

ElyraSQL is configured entirely through CLI flags, each with an environment variable fallback (handy for systemd and containers).

¶elyrasql serve

¶Memory limits (environment-only)

¶Security & full-text (environment-only)

RUST_LOG controls log verbosity (error, warn, info, debug, trace; default info).

¶Examples

Local development (open, no auth):

elyrasql serve

Single admin user:

elyrasql serve --user root --password s3cret

Multiple users with roles, plus TLS:

elyrasql serve \
  --auth admin:adminpw:admin \
  --auth app:apppw:write \
  --auth analyst:ropw:read \
  --tls-cert server.crt --tls-key server.key

Roles are admin (DDL + everything), write (DML + reads), and read (SELECT only). See Security.

¶Recommended settings

Sensible baselines by deployment profile. Start here and adjust to your hardware and workload.

¶Production (single node, exposed to applications)

Close the critical security and stability gaps first:

ELYRASQL_DATA=/var/lib/elyrasql/elyra.edb \
ELYRASQL_LISTEN=0.0.0.0:3307 \
ELYRASQL_USER=admin ELYRASQL_PASSWORD='<strong-password>' \
ELYRASQL_TLS_CERT=/etc/elyrasql/server.crt \
ELYRASQL_TLS_KEY=/etc/elyrasql/server.key \
ELYRASQL_SLOW_QUERY_MS=500 \
ELYRASQL_METRICS_LISTEN=127.0.0.1:9090 \
ELYRASQL_AUDIT_LOG=/var/log/elyrasql/audit.log \
elyrasql serve

• Always set credentials and enable TLS for client traffic — never expose an open (no-auth) listener to a network.
• Keep the password policy and login lockout at their defaults (on).
• If your transactions are small, lower ELYRASQL_MAX_FRAME_MB (e.g. 64) for tighter denial-of-service defence. Keep it ≥ your largest transaction (ELYRASQL_TXN_MAX_BYTES), or replication/binlog replay of that transaction will be rejected.
• Size the memory caps to your box: as a rough guide keep ELYRASQL_SORT_MAX_ROWS × average row size well under available RAM, and ELYRASQL_TXN_MAX_BYTES below the memory you can spare for one transaction.
• Run ANALYZE TABLE after bulk loads so the planner picks the spilling GROUP BY path directly (avoids a wasted scan) and orders joins well.

¶Cluster / replication (high availability)

Everything from the production profile, plus:

ELYRASQL_CLUSTER_SECRET='<shared-secret>' \
ELYRASQL_REPLICATION_LISTEN=0.0.0.0:3317 \
ELYRASQL_SYNC_REPLICAS=1 \
ELYRASQL_BINLOG=/var/lib/elyrasql/binlog \
elyrasql serve   # (or: elyrasql cluster …)

• Set ELYRASQL_CLUSTER_SECRET on every node so peers authenticate.
• Internal cluster/replication traffic is authenticated but not encrypted — run nodes on a private network or VPN (mTLS is planned).
• Use ELYRASQL_SYNC_REPLICAS (and optionally ELYRASQL_SYNC_STRICT) to trade a little latency for stronger durability. See Replication & HA.

¶Vector-search / OLAP heavy

• Build vector indexes after loading embeddings; the first query after a write pays a single (single-flight) rebuild, then queries are cached.
• Give the process plenty of RAM — HNSW graphs and OLAP aggregation are memory-resident up to the spill thresholds above.
• For very large GROUP BY/ORDER BY, raise ELYRASQL_SORT_MAX_ROWS / ELYRASQL_GROUP_MAX_GROUPS if you have the memory, or lower them to force earlier disk spilling on constrained hosts.

¶Local development

Defaults are fine — elyrasql serve (open, no auth, 127.0.0.1:3307).

¶Other commands

elyrasql version    # print product and version
elyrasql --help
elyrasql serve --help

¶Environment-only (systemd / Docker)

Because every flag has an env fallback, elyrasql serve with no arguments picks everything up from the environment — exactly how the systemd unit and Docker image invoke it:

ELYRASQL_DATA=/var/lib/elyrasql/elyra.edb \
ELYRASQL_LISTEN=0.0.0.0:3307 \
ELYRASQL_USER=root ELYRASQL_PASSWORD=secret \
elyrasql serve