Gå til indhold

Connect your first database

Dette indhold er ikke tilgængeligt i dit sprog endnu.

Whether you use the setup wizard, the Studio UI, or the REST API, the connect flow is the same set of decisions running through the same services. Here is what each one is actually asking.

Adminium v1 ships adapters for three engines:

Engine Connection string
PostgreSQL postgres://user:pass@host:5432/db?sslmode=require
MySQL / MariaDB mysql://user:pass@host:3306/db
SQLite sqlite:/absolute/path/to/app.db

Or skip the connection entirely and import a schema file — a pg_dump, a schema.prisma, a Rails schema.rb, and six other formats. No live database required.

Before Adminium stores anything, it connects and probes. You will see something like:

Connected — 34 ms · PostgreSQL 16.2 · read-only role

Three facts, each load-bearing:

  • Latency — a sanity check that you reached the database you meant to.
  • Server version — Adminium adapts introspection to what the version supports.
  • Capabilities — what your role can do: canRead, canWrite, canDDL.

That last one determines what you get. A role with canRead but not canWrite produces a fully functional read-only app with a banner saying so. Adminium does not offer you a Save button that will throw.

Adminium needs somewhere to keep its own tables — users, roles, connections, snapshots, page config, audit. That is the meta store, and it is a separate concern from your data connection.

You have three options:

  1. Embedded SQLite (the default) — a file under your data directory. Fine for a laptop or an evaluation. It announces itself on boot.
  2. The same database as your data, in its own schema. Convenient, and requires your role to have DDL.
  3. A separate database. The right answer for production.

One rule is enforced rather than advised:

A read-only data role means the meta store must live elsewhere. Adminium refuses same-database placement in that case, with META_PLACEMENT_INVALID, at the moment both facts are known — right after the probe.

Nothing else could work: Adminium must write its own tables, and a role that cannot write cannot host them. The full decision tree: Where to put the meta store.

Blank or all includes everything Adminium found. Otherwise, give it a comma-separated list — either fully-qualified (public.orders) or just the table name (orders) when it is unambiguous.

You are not locked in. Re-run adminium introspect after a schema change and the snapshot updates; if nothing changed, the checksum matches and it is a no-op:

Terminal window
adminium introspect --connection <id>
# Schema unchanged — kept snapshot snp_… (24 tables).

The intent shapes what gets generated:

Intent What you get
Full admin CRUD on everything, dashboards included
Read-only analytics Dashboards and browsing, no writes
CRUD Data-entry screens, minimal dashboards
Support console Lookup-first, focused on finding one record

Introspection classifies columns and proposes masks for anything that looks personal — emails, phone numbers, national IDs. It will tell you:

Proposed 7 PII mask override(s) — masking is on by default.

Masks are proposals you can review and change, but the default is masked, not exposed.