What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose a database by matching its data model and query behavior to the application, then checking whether your team can operate and support it. The Database Selection Matrix is a practical framework for comparing candidates across three areas: development, operations, and commercial considerations. It helps teams make trade-offs explicit; it does not declare one database type or product best for every application.
What is the Database Selection Matrix?
Mat Keep introduced the Database Selection Matrix in a DZone article published February 9, 2015, as a decision framework for teams responsible for database selection. It was developed with large enterprises already running multiple databases in production and seeking a systematic way to evaluate additional choices. The framework remains useful as a checklist, but the article’s examples and figures should be read in their 2015 context.
Keep wrote that “Over 80% of today’s data no longer fits neatly into the normalized row and column table formats of the past.” That is a historical claim from 2015, not a current industry measurement. Its enduring point is narrower: applications can have data needs that do not fit a single familiar structure, so teams should assess requirements rather than assume a relational database—or a newer alternative—is automatically appropriate. Read Keep’s original DZone article.
Start with the application and the organization
Before comparing products, document what the application must do and what the organization can realistically support. Include existing architecture, standards, skills, operational processes, and constraints. A database that handles a workload on paper may still be a poor choice if the team lacks the skills or integrations to run it reliably.
The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
- Describe the data, its structure, expected changes, and any large binary objects.
- List the application’s read, write, search, aggregation, and analytics patterns.
- Set availability, recovery, security, and geographic requirements.
- Identify existing programming languages, operations tools, architecture, and support expectations.
- Separate must-have requirements from preferences, and note which trade-offs are acceptable.
Compare candidates across three areas
Use the matrix to organize evidence rather than reduce the decision to a database-category label. Evaluate development fit, operational fit, and commercial fit for each candidate using the same questions.
Development: can the database serve the application?
Start with the data and the way the application needs to use it. A useful data model is not enough if the query model cannot support the application’s important access patterns.
- Data model: Does the information have a stable structure, or do records vary in shape and type? Can values include large binary objects?
- Consistency: Which updates need strong consistency, and where, if anywhere, can the application tolerate eventual consistency? Make this a workload-specific requirement, not a general preference.
- Query functionality: List required queries, ad-hoc exploration, aggregations, geospatial search, and text search. Confirm support for the actual patterns rather than relying on broad product labels.
- Integration: Does the application need analytics, business-intelligence tools, Hadoop, or a data warehouse? Check the integration path and its fit with the intended workflow.
- Language support: Verify that usable drivers exist for the programming languages the team uses.
These questions help distinguish among relational, document, key-value, wide-column, and graph approaches, but the category alone does not determine suitability. Compare concrete query and consistency needs against each candidate’s capabilities.
Operations: can the organization run it reliably?
Assess the complete operating model, including normal maintenance and failure recovery. Record requirements in measurable terms where the application has them; for example, specify recovery time objective (RTO) and recovery point objective (RPO) rather than simply asking whether disaster recovery is supported.
- Availability and recovery: Define the application’s availability SLA, RTO, and RPO. Assess automated failure recovery, maintenance availability, and cross-data-center replication.
- Scaling and locality: Check horizontal growth and partitioning options, including whether partitioning can align with query patterns. Consider geographic locality and compression where relevant.
- Security: Review authentication, authorization, encryption, and auditing against organizational requirements.
- Administration: Assess provisioning and upgrades, and whether the existing team and processes can manage the database.
- Backups and observability: Check incremental and point-in-time backup capabilities, monitoring, alerting, and integration with existing operations tooling.
- Data-center requirements: Confirm that deployment and replication needs fit the organization’s data-center arrangements.
Commercial: is the choice supportable over time?
Compare the terms and services that affect adoption and ongoing ownership. “Free” or “open source” does not by itself answer whether a product fits the organization’s licensing, support, or training needs.
- Licensing: Review the software license and whether a commercial-license option is needed.
- Pricing: Assess the relevant costs for the planned use; the 2015 matrix does not provide current prices.
- Support: Check the scope of support, support SLAs, and expectations for incident response.
- Training: Determine whether public or on-demand training is available and whether it meets the team’s needs.
Use the matrix to make the trade-offs visible
Build a comparison using the same requirements for every candidate. The axes below follow the ACME Retail example in Keep’s article and turn its scenario into a reusable evaluation structure. Record evidence for each assessment, identify unresolved questions, and distinguish a requirement that is met from one that is merely possible with additional work.
| Comparison axis | Question to answer |
|---|---|
| Data model | Does the model fit the structure, variability, and types of the application’s data? |
| Query functionality | Can it support the required queries, aggregations, geospatial or text search, and any ad-hoc access? |
| Consistency | Does its consistency behavior match the application’s correctness requirements? |
| Performance and scalability | Can it meet the workload’s needs and scale in ways compatible with query patterns and locality? |
| Availability and disaster recovery | Can the deployment meet the stated availability SLA, RTO, RPO, maintenance, and replication requirements? |
| Security and administration | Does it provide the required controls and fit the team’s provisioning, upgrade, and operations practices? |
| Integration | Can it connect to the application languages, analytics, BI, Hadoop, warehouse, and operations tools that matter? |
| Licensing | Do the software license and commercial options fit the intended use? |
| Support | Are the scope, SLA, and incident expectations acceptable? |
| Training | Can the team access suitable public or on-demand training? |
A matrix is most useful when it exposes a disqualifying mismatch or a cost the team had not considered. If two candidates both meet the essentials, compare the consequences of their remaining differences rather than treating every criterion as equally important.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Example: evaluating a vehicle fleet’s sensor data
Keep’s ACME Retail scenario describes a nationwide fleet collecting truck-sensor data to improve routing and delivery times, reduce waste, and limit breakdown-related interruptions. The example is a way to apply the matrix, not a recommendation to select a particular database. The team would first define the sensor data and how the application needs to query it, then assess consistency, scaling, availability and recovery, security and administration, integration, licensing, support, and training.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Repair Windows errors before they cause bigger problems3Fix the driver behind crashes, sound loss and screen glitchesThe article mentions MongoDB as one possible option for IoT applications and notes that Bosch SI selected it for the Bosch IoT Suite. That example does not establish that MongoDB—or any one database—is the right fit for every IoT workload. The article also quotes Morgan Stanley’s “Internet of Things is Now” research: “We do not believe traditional data storage architectures are well- suited to accommodate the volume, velocity, and variety of IoT data”. Treat that as the cited source’s view in the article’s 2015 discussion, not as a universal verdict on current database choices.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
