Comparing Two Databases Without a Scoreboard

To compare databases fairly, start with the work your application must complete. A feature checklist becomes useful only after you know which features matter and how you will operate them.

Define the Decision Before the Trial

Write down the problem that justifies considering another database. It might involve scale, operational effort, availability, or a specific data-access pattern. A vague wish for something modern cannot produce a meaningful acceptance test.

Separate requirements from preferences. Required transaction behavior, recovery objectives, and supported deployment locations may eliminate a candidate immediately. Familiar syntax and a polished demonstration are useful, but they do not replace those requirements.

Agree on who will make the decision and what evidence is needed. Include application developers, operators, and the business owner. Otherwise, each group may judge a different problem after the trial ends.

Capture the Work You Actually Perform

Inventory important reads, writes, batch loads, and maintenance activities. Record frequency, concurrency, data distribution, and response-time expectations. A database chosen for fast point lookups may behave differently during a large reporting join.

SELECT TOP (20) qs.execution_count,
       qs.total_worker_time AS total_cpu_microseconds,
       qs.total_elapsed_time AS total_elapsed_microseconds,
       qs.total_logical_reads,
       st.text AS batch_text
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY qs.total_worker_time DESC;

This SQL Server query helps identify accumulated cached workload costs. It is not a complete workload history, and cache turnover changes the evidence. Protect captured query text because it can contain sensitive values.

Combine database observations with application request traces and scheduled-work inventories. Include rare but essential operations such as month-end processing. A frequent query is not automatically the most important business operation.

Make the Test Shape Explicit

Use data that reflects important skew, relationships, and growth. Include both common and unusual parameter values. Uniformly generated rows can hide the behavior that caused the original problem.

CREATE TABLE #TrialCases
(
    CaseName varchar(40) PRIMARY KEY,
    ConcurrentUsers int NOT NULL,
    ReadPercent decimal(5,2) NOT NULL,
    RequiredP95Milliseconds int NULL,
    Notes nvarchar(200) NOT NULL
);
INSERT #TrialCases VALUES
('Interactive lookup',20,95.00,500,N'Include common and rare keys'),
('Daily ingestion',4,10.00,NULL,N'Include duplicate delivery and restart'),
('Month-end report',2,100.00,NULL,N'Use representative history');
SELECT * FROM #TrialCases ORDER BY CaseName;

These are example planning values, not recommended targets for every application. Replace them with requirements agreed by your team. The table records what to test rather than predicting any candidate's performance.

Keep correctness checks beside performance measurements. Compare returned rows, transaction outcomes, and duplicate handling. A faster operation with weaker required behavior has not passed the same test.

Compare Operations and Recovery

Ask the people who will support the system to restore a backup and investigate a failed request. Include deployment, patching, capacity changes, and monitoring. Product capability matters only when the team can use it reliably.

SELECT d.name, d.recovery_model_desc,
       MAX(b.backup_finish_date) AS latest_recorded_full_backup
FROM sys.databases AS d
LEFT JOIN msdb.dbo.backupset AS b
  ON b.database_name = d.name AND b.type = 'D'
GROUP BY d.name, d.recovery_model_desc
ORDER BY d.name;

This SQL Server inventory shows recorded backup history, not successful restore tests. Build equivalent evidence for each candidate using its supported tools. Different recovery mechanisms can still be compared against the same business objective.

Exercise failure and recovery under a controlled plan. Include the application reconnecting and resuming useful work. A healthy database service alone does not prove that the business process recovered.

Price the Complete Operating Model

Include licensing or service charges, storage, backups, network transfer, and support. Add migration effort, training, and application changes. Explain assumptions so somebody else can recalculate the comparison.

Separate current costs from growth scenarios and temporary migration costs. Avoid turning uncertain estimates into precise-looking totals. A range with stated assumptions is more honest than a single unsupported number.

Consider the cost of reversing the decision. Data extraction, application dependencies, and specialized operations can make later changes expensive. That does not prohibit a specialized product, but it belongs in the decision.

Write a Decision With Conditions

State which candidate meets the requirements and which uncertainties remain. Attach the test configuration, scripts, measurements, and failure observations. Record any condition that would cause you to reconsider.

A useful decision can favor the existing database after a small targeted improvement. It can also justify a move when the evidence supports it. The result should explain the choice without relying on a scoreboard of unrelated features.

A database comparison is not a feature-count contest, it is a test of fitness for your work.

This post was rewritten from scratch in September 2026. The original, published on 2008-06-19, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.