Pre-Engagement Questionnaire: 10 Proven Steps from Submission to 24×7 Operations

Purpose

Why the pre-engagement questionnaire comes before any recommendation

A database recommendation is only as good as the facts it rests on. When an engineer in one time zone hands a customer to an engineer in another, the facts have to live in a document, not in someone’s memory, and they have to be accurate. That is why the pre-engagement questionnaire asks for specifics rather than impressions: the engine versions actually running, the size on disk, the Linux distribution, whether the infrastructure is bare metal or a managed service, what monitoring exists, what the DR and HA arrangements really are, and what happened during the most recent outage.

The answers do three jobs at once. They select the work: which per-engine evidence we request, which checks the baseline health check runs, which engineers join the bench. They size the work: backup and restore windows, health-check duration, migration effort. And they fix the operating parameters of the engagement: named contacts, time-zone overlap, SLA tier, access model and change-approval flow. Nothing in the pre-engagement questionnaire is asked for its own sake, and the sections below show where each answer goes.

What to have at hand before completing the pre-engagement questionnaire

The form takes about twenty minutes when the details are within reach. Have the exact engine versions (SELECT version() on ClickHouse and PostgreSQL, SELECT VERSION() on MySQL), the size on disk per database rather than a guess, the Linux distribution and kernel version from /etc/os-release and uname -r, the name of the backup tool and the date of the last tested restore, and the topology of replication as it is running today. For the outage question, the ticket or incident record is better than memory: the timeline and the alerts that fired are what the first runbook is built from.

If the estate spans several engines or several environments, describe production only; staging and development are noted on the onboarding call. And if the architecture diagram you have is out of date, send it anyway with a note saying so; reconciling the diagram with the evidence pack is part of the baseline health check, and an honest starting point saves a week.

Question by question

What each block of the pre-engagement questionnaire decides

The map below is the one our Technical Account Managers work from. Each row is a block of the form, the decision or check it drives, and the artefact it produces in the engagement notes.

Contact, ambassador and time zone on the pre-engagement questionnaire

The customer ambassador is the one person who can approve a change and who receives the monthly service review. The time zone sets the overlap window in which scheduled work, drills and reviews happen, and the language of the escalation matrix. If a resident DBA exists, they become the technical counterpart and the operating model is consultative support beside them; if not, the operating model is remote DBA, where ChistaDATA holds the pager and the change-approval flow is written accordingly.

Technology stack and database size

The stack answer selects the evidence pack and the engineers. ClickHouse estates are staffed from the ChistaDATA bench directly; PostgreSQL, MySQL, MariaDB, MongoDB, SQL Server, Oracle, Db2 and the cloud DBaaS platforms are covered through the MinervaDB practice ChistaDATA was spun out of, under the same escalation matrix. Mixed estates are flagged for cross-engine runbooks, for example a PostgreSQL primary with a ClickHouse analytics or archival tier fed by CDC. Database size drives everything that scales with bytes: backup and restore windows, the duration of the baseline health check, migration sizing, and whether tiered storage should be on the table from day one.

Evidence

The read-only evidence pack requested after the pre-engagement questionnaire

Once the stack is known, the Technical Account Manager sends a short list of configuration files and catalog queries. Nothing in the list changes a running system, and customers redact passwords and keys before sending. The pack is what turns the questionnaire’s answers into a verified baseline.

-- ClickHouse: the four queries that anchor the baseline (run per node, read-only)
SELECT name, value FROM system.settings WHERE changed = 1 ORDER BY name;
SELECT name, value FROM system.server_settings WHERE changed = 1 ORDER BY name;

SELECT database, table, engine, sorting_key, partition_key,
       formatReadableSize(total_bytes) AS size, total_rows
FROM system.tables WHERE database NOT IN ('system', 'INFORMATION_SCHEMA', 'information_schema')
ORDER BY total_bytes DESC LIMIT 50;

SELECT normalizedQueryHash(query) AS fingerprint, count() AS runs,
       quantile(0.95)(query_duration_ms) AS p95_ms,
       formatReadableSize(avg(read_bytes)) AS avg_read,
       formatReadableSize(max(memory_usage)) AS max_mem,
       any(substring(query, 1, 100)) AS sample
FROM system.query_log
WHERE type = 'QueryFinish' AND event_time > now() - INTERVAL 7 DAY
GROUP BY fingerprint ORDER BY runs * p95_ms DESC LIMIT 30;

-- PostgreSQL 16+: the equivalent anchors
SELECT name, setting, unit, source FROM pg_settings WHERE source <> 'default' ORDER BY name;
SELECT relname, n_live_tup, n_dead_tup, seq_scan, idx_scan, last_autovacuum
FROM pg_stat_user_tables ORDER BY n_live_tup DESC LIMIT 50;
SELECT queryid, calls, ROUND(mean_exec_time::numeric, 2) AS mean_ms,
       shared_blks_read, LEFT(query, 100) AS sample
FROM pg_stat_statements ORDER BY total_exec_time DESC LIMIT 30;
SELECT client_addr, state, sent_lsn, replay_lsn, replay_lag FROM pg_stat_replication;

The pack is reviewed before the onboarding call, so the call spends its hour on decisions rather than discovery. Discrepancies between the pre-engagement questionnaire and the pack (a version that differs, a replica that is not replicating, a backup that has never been restored) are the first findings of the health check.

SLA

The escalation matrix the pre-engagement questionnaire populates

The services you select on the form set the SLA tier and the scope of change work; the contacts and time zone become the names and overlap window on the escalation matrix; the outage description becomes the first S1 scenario we rehearse. Severity is defined by business impact as you describe it on the onboarding call, never by which component failed.

Performance audits, health checks, security audits and data recovery are available as one-off engagements from the same form; the Technical Account Manager scopes them from the size, stack and infrastructure answers before the onboarding call.

The form

The ChistaDATA pre-engagement questionnaire

Fields marked with an asterisk are required. Please do not enter passwords, keys or connection strings anywhere on this form; the Technical Account Manager will agree a secure channel for the evidence pack after the submission is acknowledged.

Customer Name *

Website / URL *

Phone *

Email *

Name (Customer Ambassador) *

First

Last

What is your timezone ? *

When you want us to contact you for on-boarding call ? *

Date

Time

What is your Database Technology Stack ? *

• ClickHouse
• MySQL GA
• Percona Server for MySQL
• MariaDB
• MongoDB
• MyRocks
• PostgreSQL
• Hadoop
• Others/NoSQL
• DBaaS
• Google AlloyDB
• Google BigQuery
• Amazon Redshift
• Amazon Aurora
• Amazon RDS
• Snowflake
• Databricks
• Microsoft AzureSQL
• Microsoft SQL Server
• Oracle
• DB2

Do you have a resident DBA ? If yes, Please provide us your resident DBA details below: *

• YES
• NO

Resident DBA Name *

First

Last

Resident DBA Email *

Resident DBA Phone *

What is your Database Size? *

What is your Linux Distribution? *

Can you please share with us the details of your infrastructure (Bare Metal / VM / RDS / DBaaS) ? *

Do you have a dedicated Database Performance Monitoring Infrastructure ? If yes, Please share with us details: *

Do you have a DR Strategy for your Database Infrastructure ? If yes, Please explain your DR solution: *

Do you have High Availability solution for Database Infrastructure ? If yes, Please explain: *

Can you please explain the most recent Database Outage and how did you address the same ? *

What are the services from ChistaDATA you want to subscribe ? *

• Consulting and Professional Services
• Database Performance Audit, Health-Check and Recommendations
• ChistaDATA Database Infrastructure Security Audit
• ChistaDATA Data Recovery Services
• ChistaDATA 24*7 Enterprise-Class Support
• ChistaDATA Remote DBA Services

Do you have any archiving solution for the Database Infrastructure ? *

• YES
• NO

What are your serious concerns in Database Infrastructure Operations ? *

• Database Architecture and Engineering
• Performance
• Scalability
• Capacity Planning and Sizing
• Database Reliability and Failover Soultions
• High Availability
• Replication Solutions
• Disaster Recovery
• Database Infrastructure Operations Automation
• We don't have a resident DBA
• Data Security
• Database Upgrades and Migrations

What is your Database Infrastructure growth plan for next 6 months ? *

Can you please share with us the Database Infrastructure Architecture of your business ? *

Submit