← Data Console

Browse MariaDB safely, with masked columns and an audit trail

MariaDB takes the same grants as MySQL and diverges in the places that matter once you are looking at real data. The console handles both, and the differences below are the ones that change what you see on screen.

Create a read-only MariaDB user

Run against a live server, then re-connected as that user to confirm SELECT worked and INSERT and DROP were refused.

-- MariaDB 11, verified
CREATE USER 'dbshift_ro'@'%' IDENTIFIED BY 'a-strong-password';
GRANT SELECT, SHOW VIEW ON your_db.* TO 'dbshift_ro'@'%';
FLUSH PRIVILEGES;

What browsing MariaDB looks like

  • JSON is stored as LONGTEXT with a validation constraint rather than as a distinct type, and is still shown formatted.
  • TINYINT(1) is treated as a boolean, the same as MySQL, while plain TINYINT stays numeric.
  • System-versioned tables keep history the console can show you, which a plain client will not surface.
  • ENUM value lists are preserved for filtering.

What catches people out on MariaDB

Sequences exist here and not in MySQL

MariaDB has real sequence objects alongside AUTO_INCREMENT. A schema written for MariaDB may not be a MySQL schema, which matters the moment someone tries to move it.

Default collation is case-insensitive

Filtering for 'ACME' also matches 'acme'. That is usually convenient while browsing and a genuine behaviour change if the data ever moves to an engine that compares case-sensitively.

System-versioned history is real data

If a table is versioned, historical rows are queryable — including values someone believed were deleted. Worth knowing before granting access to it.

A read-only login still shows everything

The user above stops writes. It does not stop someone reading every email address, card number and salary in the database, and it does not record who did. The console adds the other half: sensitive columns are detected and masked before the rows leave the server, unmasking is granted per column to named people, and every access is logged. Access Review answers "who can see what" across every source in one report, which is the question that is very hard to answer from a pile of grants.

Start freeHow the console works

Questions

How do I create a read-only user in MariaDB?

The MySQL syntax applies: create the user, then grant SELECT and SHOW VIEW on the database. Verified against MariaDB 11 — SELECT permitted, INSERT and DROP refused.

Does the console treat MariaDB differently from MySQL?

Where the engines differ, yes: JSON-as-LONGTEXT is reported as JSON, and system-versioned tables are recognised rather than shown as ordinary tables.

More on MariaDB

Letting an AI agent read MariaDB

The read-only user above is the floor, not the ceiling — it still exposes every row it can select. What a scoped agent token changes, on this engine.

Other databases

PostgreSQL

Browse a PostgreSQL database with PII masked, follow foreign keys, and give your team read-only access without sharing the connection string.

MySQL

Browse a MySQL database from the browser with PII masked, follow foreign keys, and give teammates read-only access without sharing the root password.

SQL Server

Browse SQL Server from the browser with PII masked and per-person access, without distributing a login or installing SSMS.

Oracle

Browse an Oracle database in the browser with PII masked and per-person access, without granting a schema account to everyone who needs a look.

MongoDB

Browse MongoDB collections in the browser with PII masked — and the one configuration detail that decides whether a read-only user means anything at all.

SQLite

Browse a SQLite database in the browser, with the read-only open mode that actually prevents writes and the type behaviour that surprises people.