Production data operations

Every change to production data, reviewed before it runs.

keenbase puts a change request, a reviewer and a SQL guard between your team and the production database. Query through masked models, raise a change, get it approved, and keenbase runs exactly what was reviewed. Every step lands in the audit log.

Connects to MySQL & Aurora MySQL PostgreSQL MongoDB Atlas
CR-DML-142 · data change In review

Mark two refunded orders as refunded

model: orders · payments-prod · write host

UPDATE orders
   SET status = 'refunded'
 WHERE id IN (88412, 88413);
Guard
one statement WHERE present status is editable
Preview
2 rows · email j•••@•••••.com
AI risk
Lowprimary-key filter, 2 rows
Sign-off
✓ maker ✓ checker owner runs

How it works

From “can you run this for me?” to an audited change.

  1. 01

    Model your data

    Declare the tables and collections people may touch and, for each field, whether it is visible, editable or masked. Import a whole connection in one pass.

  2. 02

    Query safely

    The SQL and MongoDB consoles read through models only, on the read host, with masks applied and row limits capped. Hidden columns never leave the database.

  3. 03

    Raise a change

    Each change is checked against the model as it is written, with a masked before-and-after preview and an AI risk review.

  4. 04

    Approve, then run

    A checker signs off and an owner executes. keenbase queues the run inside a transaction, then tells downstream systems.

Features

Guardrails your auditors can read.

Three lanes, one review

Data, structure and MongoDB document changes all follow the same request, review and run.

PII masking everywhere

Per-model masks plus org-wide rules by column name, applied before anything is shown or cached. Built with UU PDP in mind.

AI risk review

An LLM reads the masked statement and flags its blast radius before reviewers do. Bring your own API key; raw values never leave.

Scoped access

Restrict a connection or a model to the people who need it. Anything out of scope simply doesn’t exist for them.

Structure changes, safely

Add columns, widen types and create tables with seed rows through the same review. Each target opts in.

Complete audit trail

Who did what, to which resource, from where and when. Every action is recorded for ISO 27001 reviews.

Post-execution hooks

Tell downstream systems a change landed via RabbitMQ, webhooks or Slack, with retries and a delivery log.

Read and write split

Reads go to replicas and writes to primaries, over SSH tunnels when you need them. Raw credentials never sit in keenbase’s own database.

Roles

Four roles. Only one can press run.

Roles are fixed in code, so what each person may do is the same in every organisation and simple to explain to an auditor. Access scopes then decide where they may do it.

What each keenbase role can do
Can viewer maker checker owner
View the dashboard, models and changes ✓✓✓✓
Raise, edit and submit changes —✓✓✓
Run SELECTs in the consoles —✓✓✓
Run AI risk analysis —✓✓✓
Approve, reject or send back ——✓✓
Execute an approved change ———✓
Manage connections, models, hooks and members ———✓
View the audit log ———✓

Security model

The guard is the boundary.

Every statement is parsed and checked against the model before anyone approves it. What reaches the database is regenerated from the validated syntax tree, never the text someone typed.

  • One statement at a time. No DML without a WHERE.
  • No GRANT or REVOKE, and no DDL outside the allow-listed structure changes.
  • MongoDB queries pass an allow-list of stages and operators, on declared fields only.
  • Each organisation’s data, cache and queued jobs are kept apart.

Ready for your next data patch.

Sign in, connect a database and model your first table. Your next change request is a few minutes away.

Open the console