Connect your first database
Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.
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.
Pick an engine
Section titled “Pick an engine”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.
The probe
Section titled “The probe”Before Adminium stores anything, it connects and probes. You will see something like:
Connected — 34 ms · PostgreSQL 16.2 · read-only roleThree 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.
The meta-store question
Section titled “The meta-store question”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:
- Embedded SQLite (the default) — a file under your data directory. Fine for a laptop or an evaluation. It announces itself on boot.
- The same database as your data, in its own schema. Convenient, and requires your role to have DDL.
- 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.
Choosing tables
Section titled “Choosing tables”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:
adminium introspect --connection <id># Schema unchanged — kept snapshot snp_… (24 tables).Choosing an intent
Section titled “Choosing an intent”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 |
PII masking is on by default
Section titled “PII masking is on by default”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.
- PostgreSQL · MySQL · SQLite
- Read-only sources & the meta database
- Improve the generated app with an LLM — optional, and there is a path that sends nothing anywhere.