Data editor — Overview
Every database service you deploy from Pier gets a Data tab. Open it to explore the schema, page through rows or documents, and run queries inline — without installing DBeaver, exposing the port to the internet, or running an Adminer/pgweb container alongside.
It’s part of the same Rust binary that runs your containers. Access is gated by Pier’s RBAC, and every query you run through a runner is recorded in an audit log.
Supported engines
Section titled “Supported engines”| Engine | How Pier connects | Browse | Query runner |
|---|---|---|---|
| PostgreSQL (incl. PostGIS, TimescaleDB) | native sqlx driver over TCP | databases · schemas · tables · views · structure · rows | arbitrary SQL |
| MySQL / MariaDB | native sqlx driver over TCP | databases · tables · views · structure · rows | arbitrary SQL |
| MongoDB | mongosh inside the container (docker-exec) | databases · collections · documents | mongosh scripts |
| Redis / Valkey | native redis client over TCP | keys (SCAN) · type-aware values · TTL | raw commands |
The SQL engines and Redis use native Rust drivers; MongoDB is driven through mongosh already present in the official image, so Pier avoids pulling a heavy native Mongo driver into the binary.
Where to find it
Section titled “Where to find it”- Open a database resource (anything you deployed from the Databases catalog category).
- Click the Data tab. The tab only appears for database services.
- Pier detects the engine and shows the matching view:
- SQL engines → a schema/table browser with an inline SQL Runner.
- MongoDB → a database/collection browser with a Mongo Shell.
- Redis → a key browser with a command box.
How the connection works
Section titled “How the connection works”Pier core runs natively on the host, next to the Docker daemon. Private database services aren’t published to a host port, so Pier reaches them over the pier-net Docker network, dialing the container’s internal IP and port (e.g. 5432, 3306, 6379). If a port is published, the loopback (127.0.0.1:{host_port}) is used as a fallback.
Credentials are read from the service’s encrypted environment (POSTGRES_PASSWORD, MYSQL_ROOT_PASSWORD, MONGO_INITDB_ROOT_PASSWORD, REDIS_PASSWORD, …), decrypted in memory at request time. They’re never shown in the UI or written to logs.
Because everything happens server-side over the internal network, you don’t have to expose the database to the internet to inspect it.
What it is — and isn’t
Section titled “What it is — and isn’t”The data editor is an 80% tool: it covers the day-to-day — eyeball some rows, check a schema, run a quick SELECT, fix one record, inspect a key. It deliberately does not try to replace TablePlus/DataGrip/Compass for ER diagrams, query-plan profiling, or schema migrations.
For a self-hosted PaaS that’s the right scope: most of the time you just want to see your data without leaving the dashboard.
Next steps
Section titled “Next steps”- Browsing your data — schemas, tables, structure, rows, collections and keys.
- SQL Runner — running queries against PostgreSQL and MySQL/MariaDB.
- MongoDB & Redis — the Mongo Shell and the Redis key browser.
- Access & audit — RBAC roles and the query audit log.