A Database Control Plane That Respects the Source of Truth

DBMason runs as one Payload and Next.js process, with SQLite holding control-plane metadata. That local store is useful for application users, encrypted connection secrets, RBAC, and append-only audit events. It is not a shadow catalog. PostgreSQL and MySQL continue to own their databases, principals, grants, and runtime statistics.

The application reads the live engine catalog when an operator needs inventory. It does not copy those catalogs into SQLite, and it does not keep idle connection pools open. This reduces the number of competing states an operator has to reconcile. If a principal changes in the managed server, the next inspection starts from the server’s reality rather than an old control-plane snapshot.

DBMason control plane
  -> SQLite: users, protected configuration, RBAC, audit events
  -> PostgreSQL/MySQL: live catalogs, principals, grants, metrics

The control plane should explain and manage the engine’s state, not quietly replace it with a copy.

PostgreSQL and MySQL share concepts, but their permission models are not interchangeable. DBMason keeps their behavior in isolated adapters rather than spreading shared SQL conditionals through the product. The UI can describe a lifecycle operation consistently while the adapter maps it to the rules the selected engine actually supports.

The difference is visible in identity and access. PostgreSQL has roles and a database CONNECT grant. MySQL accounts are explicit user@host identities, and MySQL does not have the same database-owner or per-database CONNECT model. DBMason’s connect, read, write, and developer presets are therefore engine-mapped, not a promise that both servers behave identically.

The v0.2.1 release is validated against PostgreSQL 17 and MySQL 8.4 LTS. We state that compatibility window directly rather than assuming every server version behaves the same. New engines or versions belong in the adapter and compatibility matrix only after their behavior can be tested honestly.

DBMason can create databases, create restricted principals, reconcile existing access, enable or disable login, rotate a password once, and protect deletion through lifecycle controls. In the data workspace, relation browsing and row-returning SQL run through a transient, nonprivileged engine account. The workspace is read-only by design.

That design is narrower than an unrestricted database console, and intentionally so. A browser control plane should not turn a convenient query panel into an unbounded administrative shell. Write and DDL workspaces, saved queries, and query history remain outside the current release rather than appearing behind a label that suggests stronger guards than the implementation provides.

Audit events record control-plane actions, and Payload application RBAC limits who can perform them. Those layers do not change the managed server into a DBMason-owned system. They give the operator a reviewable path for the actions DBMason is designed to mediate.

PostgreSQL statistics and pg_stat_io can describe database activity. MySQL exposes server-status and schema metrics. Neither source provides a trustworthy measurement of host or container CPU and RAM utilization. DBMason reports that boundary instead of manufacturing a percentage from unrelated engine counters. Host telemetry requires an external metrics provider.

The same clarity applies to the rest of the current scope. Built-in backups, saved administrator credential rotation, a visual multi-schema grant planner, high-availability control-plane storage, and host telemetry are not part of v0.2.1. A production operator should know those limits before choosing how DBMason fits into a wider platform.

For us, a useful control plane is not the one that claims ownership of every layer. It is the one that keeps its own state small, reads the managed system directly, models engine differences explicitly, and refuses to display confidence it has not earned. That is the foundation DBMason is built on.