MinervaDB FAQ · Database infrastructure engineering, answered by the engineers who do it
MinervaDB FAQ: 40 Engineering Answers on Every Database We Run
The MinervaDB FAQ answers what architects, CIOs, CTOs, CDOs and DBA leads ask before and during an engagement: which engines and clouds we cover, how we tune, scale and protect them, how we secure them, what 24×7 support commits to, and how we move data between platforms. It covers PostgreSQL, MySQL, MariaDB, SQL Server, Oracle, Exadata, IBM Db2, MongoDB, SAP HANA, ClickHouse, Trino, Cassandra, Redis, Valkey and Milvus, plus AWS, Azure, Google Cloud, Snowflake and Databricks.
Twelve topics
How this MinervaDB FAQ is organised
Each topic groups the questions we are asked most, answered with the mechanism, the evidence we read and, where it helps, the exact query or configuration we run. Figures show how the pieces fit together across engines.
Company and model
Who we are, who we serve, how we work with your team.
Engines and clouds
Relational, NoSQL, analytics, vector and every major DBaaS.
Performance
Evidence first: statement time, waits, plans.
Scalability
Replicas, caching, offload, partitioning, sharding.
HA and DR
Four resilience tiers and how we prove them.
Reliability
SLOs, observability and integrity checks.
Security
Least privilege, RLS, audit, compliance evidence.
Cloud and FinOps
DBaaS engineering and cost levers per cloud.
Migration
Zero-downtime moves and Oracle and Db2 exits.
Data and AI
Lakehouse, MLOps, vectors and private RAG.
Support and SLA
Severity targets, incident ownership, GCCs.
Engagement and contact
How work starts and how to reach us.
01 · Company and model
MinervaDB FAQ: who we are and how we work
MinervaDB is a specialist database infrastructure firm, not a generalist consultancy with a data practice. This part of the MinervaDB FAQ explains the model behind every engagement.
What does MinervaDB do?
MinervaDB is a vendor-neutral, full-stack database infrastructure company covering architecture, engineering, 24×7 operations and data analytics. Practice areas include performance engineering, scalability, high availability and disaster recovery, data reliability engineering, data science and MLOps, cloud database operations and cloud FinOps.
Who does MinervaDB work with?
More than 900 enterprises, served from 46 cities, across banking and fintech, insurance, healthcare and life sciences, telecom, SaaS, retail and CPG, manufacturing and the public sector. Global Capability Centres are a growing share of the work.
Is MinervaDB tied to a database vendor or cloud?
No. We sell no licences and earn no referral fees, so recommendations follow the workload. That includes advising against an engine or managed service, even one we support, when it is the wrong fit.
Do you replace our internal database team?
Usually we work alongside it. Common patterns are night and weekend coverage, escalation for hard incidents, and specialist projects such as HA design, audits or migrations. Knowledge transfer and documentation are default deliverables, not extras.
02 · Engines and clouds
MinervaDB FAQ: engine and cloud coverage
Most estates run several engines at once. The MinervaDB FAQ coverage map below lists every self-managed engine, legacy platform and managed cloud service our engineers design, operate and support 24×7.
Figure 1. MinervaDB FAQ coverage: 28 engines and platforms, plus the managed database services of AWS, Azure, Google Cloud and the major vendor clouds.
Which database engines does MinervaDB support?
PostgreSQL, MySQL, MariaDB, SQL Server, SAP HANA, MySQL HeatWave, Oracle Database, Oracle Exadata, IBM Db2 for LUW and z/OS, MongoDB, CouchDB, Redis, Valkey, Cassandra, HBase, Neo4j, ClickHouse, Trino, Vertica, Greenplum, CockroachDB, TiDB, Milvus, pgvector and Pinecone, with Apache Kafka and Confluent for streaming.
Which managed cloud databases do you engineer?
On AWS: RDS, Aurora, DynamoDB, ElastiCache, MemoryDB, Keyspaces and Redshift. On Azure: Azure SQL Database and Managed Instance, Azure Database for PostgreSQL and MySQL, Cosmos DB and Azure Cache for Redis. On Google Cloud: Cloud SQL, AlloyDB, Spanner, Bigtable, Memorystore and BigQuery. Also Snowflake, Databricks, MongoDB Atlas, ClickHouse Cloud, Redis Cloud and DataStax Astra.
Do you support Oracle, Exadata and IBM Db2 on z/OS?
Yes, as a dedicated practice: tuning and 24×7 operation of the current estate, plus modernization where it pays. See Oracle consulting and Db2 consulting.
How is ClickHouse work delivered?
With our sister company ChistaDATA, which specialises in open-source ClickHouse consulting, support and managed services: MergeTree design, Keeper operations, replication and ingestion from Kafka.
03 · Performance engineering
MinervaDB FAQ: performance and query tuning
Performance problems are rarely mysteries; they are decisions made without measurement. The MinervaDB FAQ answers here describe the evidence we read first on each engine, and the queries below are the ones our engineers run in the first hour.
How does MinervaDB approach performance optimization?
We rank statements by total database time, not by the slowest single run, then read the plan and wait profile of the top few. Fixes follow in order of cost: indexes and query shape, configuration, connection pooling, then hardware or topology.
What evidence do you collect first?
pg_stat_statements and wait events for PostgreSQL, performance_schema digests for MySQL and MariaDB, Query Store and wait stats for SQL Server, AWR and ASH for Oracle where Diagnostics Pack is licensed, MON_GET functions for Db2, the profiler for MongoDB and system.query_log for ClickHouse.
Can you fix slow queries without application changes?
Often. Covering and partial indexes, statistics targets, plan guides or Query Store plan forcing, partition pruning and pool sizing change behaviour without a deploy. When the query shape itself is the problem, we hand the rewrite to your developers with a before-and-after plan.
How do you prove an optimization worked?
Each change has a baseline and a validation: total time and calls for the statement, p95 and p99 latency, buffer reads and CPU per transaction, measured over the same workload window before and after.
SQL · PostgreSQL and MySQL: top statements by total database time
-- PostgreSQL 13+ (pg_stat_statements): where database time actually goes
SELECT queryid,
calls,
ROUND(total_exec_time::NUMERIC / 1000, 1) AS total_s,
ROUND(mean_exec_time::NUMERIC, 2) AS mean_ms,
ROUND(100 * total_exec_time / SUM(total_exec_time) OVER (), 1) AS pct_db_time,
shared_blks_read,
temp_blks_written,
LEFT(query, 80) AS query_head
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 15;
-- MySQL 8.0+ (performance_schema): the same question, answered by statement digest
SELECT digest_text,
count_star AS calls,
ROUND(sum_timer_wait / 1e12, 1) AS total_s,
ROUND(avg_timer_wait / 1e9, 2) AS mean_ms,
sum_rows_examined,
sum_no_index_used
FROM performance_schema.events_statements_summary_by_digest
ORDER BY sum_timer_wait DESC
LIMIT 15;
T-SQL and ClickHouse SQL · Query Store and system.query_log
-- SQL Server 2016+ (Query Store): top queries by total duration over the last 24 hours
SELECT TOP (15)
q.query_id,
SUM(rs.count_executions) AS executions,
SUM(rs.avg_duration * rs.count_executions) / 1000000.0 AS total_s,
MAX(rs.max_dop) AS max_dop,
COUNT(DISTINCT p.plan_id) AS plan_count
FROM sys.query_store_query AS q
JOIN sys.query_store_plan AS p ON p.query_id = q.query_id
JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id = p.plan_id
WHERE rs.last_execution_time >= DATEADD(HOUR, -24, SYSUTCDATETIME())
GROUP BY q.query_id
ORDER BY total_s DESC;
-- ClickHouse 23.x+ (system.query_log): heaviest query shapes by bytes read
SELECT normalized_query_hash,
count() AS runs,
quantile(0.99)(query_duration_ms) AS p99_ms,
formatReadableSize(sum(read_bytes)) AS read_total,
any(substring(query, 1, 80)) AS sample
FROM system.query_log
WHERE type = 'QueryFinish'
AND event_date >= today() - 1
GROUP BY normalized_query_hash
ORDER BY sum(read_bytes) DESC
LIMIT 15;
04 · Scalability
MinervaDB FAQ: scaling ahead of demand
Growth should arrive as a planning item, not an outage. This MinervaDB FAQ section shows the order in which we consider scaling moves and the metric that proves each one.
Figure 2. The MinervaDB FAQ scaling decision flow: the cheapest move that buys enough runway, verified by a named metric.
How do you choose between replicas, caching, sharding and vertical scaling?
From the saturation profile. Read-heavy load goes to replicas or a cache, analytical scans move to a columnar engine, and only sustained write or size limits justify sharding, which is the hardest move to undo.
How do you design a shard key?
Against the real access pattern: high cardinality, even write distribution, and the key present in the hot queries so they stay single-shard. We model skew on production samples and design the re-sharding path before the first shard exists.
Do you build multi-region deployments?
Yes: Cassandra multi-DC, Aurora Global Database, Spanner, Cosmos DB, PostgreSQL and MySQL with cross-region replicas, and MongoDB zone sharding for data residency, each with latency and consistency trade-offs documented.
05 · High availability and disaster recovery
MinervaDB FAQ: availability, backups and recovery
Resilience is a property that has to be engineered and then proven. The MinervaDB FAQ answers below map each failure you plan for to a tier, and each tier to the mechanism on your engine.
Figure 3. Four resilience tiers in the MinervaDB FAQ; RPO and RTO values are illustrative design targets until measured in your drills.
Which high-availability technologies do you implement?
Patroni with etcd for PostgreSQL, Group Replication, InnoDB Cluster and Galera for the MySQL family, Always On availability groups for SQL Server, Data Guard for Oracle, HADR for Db2, replica sets for MongoDB, HANA system replication, Redis Sentinel and Cluster, and Keeper-based replication for ClickHouse.
How do you set RPO and RTO?
In business terms first: what a minute of downtime and a minute of lost writes cost. The answer picks the tier, and the tier picks the mechanism. We then measure the achieved values in drills and report the gap.
How do you verify backups?
By restoring them. Tools such as pgBackRest verify, RMAN VALIDATE and RESTORE … VERIFYONLY check integrity; a timed restore into an isolated environment proves recoverability. Copies sit in object storage with object lock, so a compromised host cannot rewrite them.
How often do you run disaster-recovery drills?
Quarterly by default, or as contracted: a restore drill and a failover drill, each with a written runbook, fencing steps, the measured RPO and RTO and the fixes that follow.
Shell + SQL · Patroni, replication lag, Group Replication and backup verification
# Patroni 3.x: cluster state, roles, timeline and lag in one view
patronictl -c /etc/patroni/patroni.yml list
-- PostgreSQL 10+: replication lag per standby, measured on the primary
SELECT application_name,
state,
sync_state,
pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), replay_lsn)) AS replay_lag_bytes,
replay_lag
FROM pg_stat_replication
ORDER BY application_name;
-- MySQL 8.0+ Group Replication: every member ONLINE, exactly one PRIMARY
SELECT member_host, member_state, member_role, member_version
FROM performance_schema.replication_group_members;
# pgBackRest 2.x: backups are only trusted after a verify and a timed test restore
pgbackrest --stanza=${PG_STANZA} verify
pgbackrest --stanza=${PG_STANZA} info
06 · Data reliability engineering
MinervaDB FAQ: observability, SLOs and integrity
Data reliability engineering brings SRE discipline to the data tier. In this MinervaDB FAQ topic, “is the database healthy?” always has a numerical answer.
What does data reliability engineering mean at MinervaDB?
Explicit SLOs for latency, availability and freshness; error budgets that decide when to pause change; alerts on leading indicators such as replication lag and pool saturation; and scheduled failure drills.
Which monitoring stacks do you work with?
Prometheus and Grafana with engine exporters, Datadog, New Relic, Percona Monitoring and Management, CloudWatch with Performance Insights, Azure Monitor and Google Cloud Monitoring, all fed from engine-native views.
How do you check data integrity?
amcheck and data checksums for PostgreSQL, DBCC CHECKDB for SQL Server, RMAN VALIDATE for Oracle, validate() for MongoDB, and checksum reconciliation between primary and replicas or between source and target during migrations.
07 · Security and compliance
MinervaDB FAQ: database security and audit evidence
Security questionnaires now arrive before purchase orders. This MinervaDB FAQ section covers the controls we engineer and the evidence they produce.
What security controls do you implement?
TLS 1.2 or 1.3 in transit, encryption at rest with KMS, Key Vault or Cloud KMS, least-privilege roles, row and column security, dynamic masking outside production, secrets in a secrets manager, patching to a schedule and audit logs shipped outside the database host.
Which compliance frameworks do you support?
SOC 2, ISO 27001, HIPAA, PCI DSS, GDPR, India’s DPDP Act and RBI requirements at the database layer, with hardening against CIS Benchmarks and NIST CSF 2.0. See database security services.
How do your engineers access our systems?
Through just-in-time, per-engagement credentials with MFA, via your bastion or PAM tooling with session recording. Customer data never leaves your environment and never enters a third-party AI tool.
SQL · PostgreSQL: least-privilege role and row-level security with verification
-- PostgreSQL 15+: least-privilege read role plus row-level security per tenant
CREATE ROLE app_reader NOLOGIN;
GRANT USAGE ON SCHEMA sales TO app_reader;
GRANT SELECT ON ALL TABLES IN SCHEMA sales TO app_reader;
ALTER DEFAULT PRIVILEGES IN SCHEMA sales GRANT SELECT ON TABLES TO app_reader;
-- Login role; the secret is injected by the secrets manager, never written in a file
CREATE ROLE svc_reporting LOGIN PASSWORD '${PG_REPORTING_PASSWORD}' IN ROLE app_reader;
ALTER TABLE sales.orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY pol_orders_tenant_read
ON sales.orders
FOR SELECT
TO app_reader
USING (tenant_id = current_setting('app.tenant_id')::BIGINT);
-- Verify: RLS is on and the policy exists
SELECT c.relname, c.relrowsecurity, p.policyname, p.roles
FROM pg_class AS c
JOIN pg_policies AS p ON p.tablename = c.relname
WHERE c.relname = 'orders';
08 · Cloud DBaaS and FinOps
MinervaDB FAQ: managed databases and cloud cost
Managed services remove host work, not engineering. The MinervaDB FAQ figure below maps each cost driver to the lever we pull on AWS, Azure and Google Cloud.
Figure 4. MinervaDB FAQ FinOps levers: every saving is tied to a billing line and checked against a performance metric.
How do you reduce cloud database cost?
We join billing exports to engine telemetry, then right-size compute, fix the statements that burn it, match storage class and provisioned IOPS to measured demand, trim backup and snapshot sprawl, cut cross-zone traffic and commit only the steady baseline. See cloud database FinOps.
Should we run self-managed or DBaaS?
It depends on the extensions, versions and parameters you need, your team’s depth, compliance scope and the three-year cost at your scale. We compare both on your workload and state the trade-offs; either answer is acceptable to us.
Do you support repatriation from the cloud?
Yes. When the economics no longer work, we plan the move back to your own hardware or colocation with the same CDC-based, reconciled cutover we use for any migration.
GoogleSQL · BigQuery: the queries behind the bill
-- BigQuery: the 20 most expensive queries of the last 30 days, by bytes billed and slot hours
SELECT user_email,
job_id,
ROUND(total_bytes_billed / POW(1024, 4), 3) AS tib_billed,
ROUND(total_slot_ms / 1000 / 3600, 1) AS slot_hours,
LEFT(query, 80) AS query_head
FROM `region-us`.INFORMATION_SCHEMA.JOBS
WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
AND job_type = 'QUERY'
AND state = 'DONE'
ORDER BY total_bytes_billed DESC
LIMIT 20;
09 · Migration and modernization
MinervaDB FAQ: migrations without drama
Every consequential migration is rehearsed, reconciled and reversible. These MinervaDB FAQ answers cover cross-engine moves, cloud moves and the exit from Oracle and Db2.
How do you run a near-zero-downtime migration?
Bulk load plus change data capture keeps source and target in sync; row counts and checksums reconcile them; a shadow period runs reads on the target; the cutover is gated, timed and rehearsed, with reverse replication ready for rollback.
Can you move Oracle or Db2 workloads to PostgreSQL?
Yes, workload by workload. Each is assigned migrate, refactor or retain after an inventory of schemas, PL/SQL, jobs and integrations. Analytical workloads often land on ClickHouse instead. See data modernization.
How do you handle major version upgrades?
Through logical replication or blue-green where the engine allows, pg_upgrade with a tested fallback, and MySQL 8.0 to 8.4 LTS checks with the upgrade checker, each rehearsed on a production-sized copy first.
10 · Data science and AI
MinervaDB FAQ: data platforms for analytics and AI
Most AI programmes stall on data engineering, not on the model. This MinervaDB FAQ topic covers the platform underneath: capture, lakehouse, features, vectors and governance.
Figure 5. The MinervaDB FAQ data and AI reference architecture, governed at the database and operated 24×7.
What does the Data Science and AI practice cover?
Real-time analytics platforms on ClickHouse and PostgreSQL, production machine learning for forecasting, pricing and fraud, MLOps on Vertex AI, SageMaker, Azure ML, Databricks and Kubernetes, private generative AI inside your VPC, and 24×7 operation of all of it.
Milvus or pgvector?
pgvector keeps vectors next to transactional data with one access model and suits corpora in the low tens of millions per tenant. Milvus scales retrieval independently, with HNSW, IVF and DiskANN indexes and partition-level isolation. We benchmark recall and p99 latency on your corpus before choosing.
Can generative AI run without data leaving our environment?
Yes. Retrieval, embeddings and the language model run inside your VPC, retrieval respects the caller’s entitlements, and evaluation and guardrails run on every change, mapped to GDPR, DPDP, HIPAA and the EU AI Act.
SQL · pgvector: HNSW index and tenant-filtered retrieval
-- pgvector 0.8.0+ on PostgreSQL 16+: tenant-filtered semantic retrieval for RAG
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE doc_chunks (
chunk_id BIGINT GENERATED ALWAYS AS IDENTITY,
tenant_id BIGINT NOT NULL,
body TEXT NOT NULL,
embedding vector(1024) NOT NULL,
CONSTRAINT pk_doc_chunks PRIMARY KEY (chunk_id)
);
CREATE INDEX CONCURRENTLY idx_doc_chunks_embedding_hnsw
ON doc_chunks USING hnsw (embedding vector_cosine_ops)
WITH (m = 16, ef_construction = 64);
SET hnsw.ef_search = 100; -- recall vs latency, measured per corpus
SET hnsw.iterative_scan = relaxed_order; -- 0.8.0+: keeps filtered queries from under-returning
SELECT chunk_id, body
FROM doc_chunks
WHERE tenant_id = $1
ORDER BY embedding <=> $2
LIMIT 8;
11 · Support and SLA
MinervaDB FAQ: 24×7 support and incident response
Databases do not keep business hours. This MinervaDB FAQ section states the response targets and how every incident is owned through to a written root cause.
What are MinervaDB’s response times?
Severity 1 in 15 minutes, 24×7×365; Severity 2 in 12 hours; Severity 3 in 24 hours; Severity 4 in 48 hours.
Which support models do you offer?
24×7 consultative support, remote DBA services, fully managed operations, embedded engineering, fixed-scope audits and a Fractional Chief Data Officer for data leadership.
How is an incident handled?
A named senior engineer owns it from first response to root cause, works from engine telemetry, makes changes behind a verification and rollback gate, and closes it with a written RCA and prevention actions.
Do you work with Global Capability Centres?
Yes, as an embedded, vendor-neutral database engineering function for GCCs in India, EMEA and APAC, with knowledge transfer built in so the centre’s own engineers grow with each engagement.
12 · Engagement and contact
MinervaDB FAQ: starting an engagement
Every engagement follows the same path: discover, design, deliver, then operate and improve. The last MinervaDB FAQ questions cover how to start and whom to contact.
How does an engagement start?
With a conversation with an engineer, never a salesperson, then a short assessment of the estate that ranks findings by risk and effort. From there, work is scoped as an audit, a project, embedded engineering or 24×7 managed operations.
How do we contact MinervaDB?
Book a consultation online, email contact@minervadb.com or call +1 (844) 588-7287. Existing clients reach support at support@minervadb.com.
Guidance in this MinervaDB FAQ is general. Test every change, upgrade, failover and migration step in a non-production environment first, verify backups by restoring them, and maintain a robust disaster-recovery posture.
| Function | Contact |
|---|---|
| Global sales, 24×7 | +1 (844) 588-7287 (toll free, USA) · +1 (415) 212-6625 (USA) · +1 (778) 770-5251 (Canada) |
| Fax | +1 (209) 314-2364 |
| General, sales and consulting | contact@minervadb.com |
| Support | support@minervadb.com |
| Remote DBA | remotedba@minervadb.com |
| Founder and Principal | Shiv Iyer · shiv@minervadb.com |
| California office | MinervaDB Inc., 440 N Barranca Ave #9718, Covina, CA 91723 |
| Delaware office | MinervaDB Inc., PO Box 2093, Philadelphia Pike #3339, Claymont, DE 19703 |
Further reading: MongoDB consulting · 24×7 enterprise support · TiDB support · consultative support · PostgreSQL documentation
A question this MinervaDB FAQ does not answer?
Ask a principal engineer directly about your workload, platform or commitments. contact@minervadb.com · +1 (844) 588-7287.