How to Give Metricfixer Safe Database Access

Use this guide when Metricfixer needs safe database access to diagnose a data-related issue, reproduce a bug, prepare a staging environment, inspect tracking or ecommerce records, or apply an approved database change.

When to use this guide

This guide applies when a support task requires access to database records, schema information, migrations, data exports, or database logs.

Typical cases include:

• investigating missing orders, leads, events, conversions, users, tickets, subscriptions, or ecommerce records;
• checking whether application data is stored correctly before it is sent to analytics, ads, CRM, or reporting systems;
• debugging migrations, queues, failed jobs, cron tasks, imports, exports, or integrations;
• creating or refreshing a staging environment;
• reviewing database schema, indexes, relations, or data consistency related to the ticket;
• running an approved migration or one-time data repair;
• verifying an approved production change after deployment.

Preferred workflow

Metricfixer normally uses this order of preference:

1. Use screenshots, logs, exported reports, or query results if direct database access is not required.
2. Use a sanitized staging database whenever the issue can be reproduced outside production.
3. Use a limited read-only production user for diagnostics when production data must be inspected.
4. Use a reviewed migration or SQL script for production changes only after backup and approval.
5. Revoke temporary access and rotate temporary credentials after the ticket is completed.

Choose the minimum safe access level

1. No direct database access

Use this when you can provide the required information through screenshots, CSV exports, application logs, admin reports, or query results produced by your own administrator. This is preferred for simple diagnostics.

2. Sanitized database dump

Use this when Metricfixer needs to reproduce the issue locally or in staging but does not need live database access. The dump should include only the tables and columns needed for the task and should remove or mask unnecessary personal data.

3. Staging database access

Use this when Metricfixer needs to test fixes, migrations, imports, exports, queues, or integrations in a non-production environment. A staging database user may usually have read/write access to the staging database only.

4. Production read-only access

Use this when the issue cannot be reproduced in staging and Metricfixer must inspect live production records. The user should be limited to read-only permissions, specific databases, schemas, tables, or views related to the task.

5. Production write or migration access

Use this only when an approved production data change is required. Production write access is not a standard diagnostic access level. It requires a current backup, written approval, a defined script or migration, a rollback plan where possible, and post-change verification.

Before you provide database access

Please add the following information to the ticket:

• database engine and version, such as MySQL, MariaDB, PostgreSQL, MongoDB, SQL Server, SQLite, Supabase, Firebase, BigQuery, or another system;
• environment: staging, production, development, read replica, managed database, shared hosting, VPS, cloud database, or local export;
• database name, schema name, and relevant table or collection names if known;
• what data problem should be checked and which records are affected;
• whether the database contains personal data, order data, payment-related data, health data, children’s data, or other sensitive information;
• whether a staging database or sanitized copy is available;
• how access should be made: provider invite, temporary user, SSH tunnel, VPN, IP allowlist, private network, or uploaded export;
• who can approve production data changes, if any are required;
• confirmation that a recent backup exists before any production write operation.

Recommended permission model

Create a separate temporary database user for Metricfixer. Use a ticket-specific name when possible, for example:

• metricfixer_readonly for production diagnostics;
• metricfixer_staging for staging work;
• metricfixer_ticket_1234 for a temporary ticket-specific user.

Limit the user to the environment and data required for the task. Avoid global privileges, system databases, unrelated projects, unrelated schemas, administrative roles, and permission delegation.

Staging database access

For staging work, the safest setup is:

• a separate staging database, not the live production database;
• sanitized or reduced production-like data where possible;
• a temporary user limited to the staging database;
• read/write permissions only when testing or applying changes on staging requires them;
• no access to production customer data unless it is necessary and approved;
• the ability to reset or refresh staging after the work is completed.

Production read-only access

For production diagnostics, prefer a read-only user or read-only replica. The user should be able to inspect only what is needed for the ticket.

A production read-only user should not have permissions such as:

• INSERT, UPDATE, DELETE, TRUNCATE, DROP, ALTER, or CREATE;
• GRANT OPTION, superuser, owner, root, DBA, or unrestricted admin rights;
• access to system databases or unrelated application databases;
• access to tables or columns unrelated to the support task, where table-level or view-level restrictions are practical.

Production data changes

Metricfixer may need to run a migration, repair records, update mapping data, remove duplicates, fix inconsistent states, or correct a one-time import issue. Production data changes are handled as a controlled operation.

Before any production write operation, please make sure that:

• a recent database backup or snapshot exists and can be restored;
• the exact change is described in the ticket;
• the SQL script, migration, admin action, or manual repair is reviewed;
• the Customer gives written approval for the production change;
• a maintenance window is agreed when the risk requires it;
• a rollback plan exists where technically possible;
• the result can be verified after the change.

Database dumps and anonymization

If you provide a database dump, please minimize it before sharing:

• include only the database, tables, collections, rows, and time period needed for the task;
• remove or mask passwords, password reset tokens, API tokens, OAuth tokens, session data, and private keys;
• remove or mask unnecessary names, emails, phone numbers, addresses, IP addresses, order notes, and user-generated content;
• do not include full payment card data or bank credentials;
• replace real customer records with test records when possible;
• compress and encrypt large dumps when needed;
• delete temporary dump files and download links after the work is completed.

Connection methods

Choose a connection method that fits your security policy:

• Managed database invite: add Metricfixer with a limited role in your provider dashboard, if supported.
• Temporary database user: create a limited user and revoke it after the ticket.
• SSH tunnel or VPN: use this when the database is not publicly reachable.
• IP allowlist: restrict access to the agreed source IP when practical.
• Read replica: use this for production diagnostics when available.
• Sanitized export: use this when live access is not required.

How to share credentials safely

Do not send database passwords or connection strings by ordinary email or public chat. Use the secure method agreed in the ticket, such as a protected secret field, a temporary provider invite, or another approved secure channel.

If a temporary password or connection string must be shared, it should be limited, short-lived, and rotated after the ticket is completed.

Examples your database administrator can adapt

The exact commands depend on your database engine, hosting provider, schema, and security policy. The examples below are only starting points for your administrator.

MySQL or MariaDB read-only example

CREATE USER 'metricfixer_readonly'@'allowed_host' IDENTIFIED BY 'temporary-strong-password';
GRANT SELECT ON `production_database`.* TO 'metricfixer_readonly'@'allowed_host';
-- Do not grant GRANT OPTION, ALTER, DROP, DELETE, UPDATE, INSERT, SUPER, or global privileges.

PostgreSQL read-only example

CREATE ROLE metricfixer_readonly LOGIN PASSWORD 'temporary-strong-password';
GRANT CONNECT ON DATABASE production_database TO metricfixer_readonly;
GRANT USAGE ON SCHEMA public TO metricfixer_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO metricfixer_readonly;
-- Add table, schema, and default privilege rules according to your own database policy.

MongoDB read-only example

// Create a temporary user with the built-in "read" role on the required database only.
// Avoid admin, root, readWriteAnyDatabase, dbAdminAnyDatabase, and cluster-wide roles.

What not to provide

• database root, superuser, owner, DBA, or unrestricted admin credentials;
• hosting or cloud master account credentials when a limited database user is enough;
• production write access for diagnostics;
• GRANT OPTION or permissions that let Metricfixer create other users or expand access;
• full production dumps containing unrelated customer data;
• full payment card numbers, bank credentials, government IDs, health data, children’s data, or other unnecessary sensitive data;
• personal employee accounts that cannot be revoked after the ticket;
• production .env files when only database access is required.

If you cannot provide direct database access

If your security policy does not allow external database access, Metricfixer can often work in client-executed mode. In that case, we may ask you to:

• run specific read-only queries and send the output;
• provide redacted screenshots or CSV exports;
• create a sanitized staging copy;
• apply a reviewed SQL script or migration yourself;
• share logs or error output instead of credentials;
• join a supervised remote session if the task cannot be completed otherwise.

How to revoke access after completion

1. Disable or delete the temporary database user.
2. Remove IP allowlist entries, VPN access, SSH tunnel access, or provider invitations that were created for the ticket.
3. Rotate any temporary database passwords or connection strings.
4. Delete temporary database dumps, exports, archive files, and download links.
5. Confirm that no production credentials were added to GitHub, documentation, logs, or shared files.
6. Keep the backup or rollback record according to your own retention policy.

Checklist before work can start

• Metricfixer has the minimum access needed for the agreed task.
• The access is temporary and limited to the relevant database, schema, tables, collections, or environment.
• Production write access is not provided unless the task requires it and written approval is recorded.
• A recent backup exists before any production data change.
• Unnecessary personal data and secrets have been removed or masked.
• There is a clear plan to revoke access after the ticket is completed.