Choosing the Right Database: A Decision Framework for Modern Engineering Teams

Selecting the right database is one of the most consequential architectural decisions a team can make. It's a choice that echoes through years of development, impacting performance, scalability, operational complexity, and ultimately, the bottom line.

The wrong database doesn't just cause technical headaches; it creates a drag on feature velocity and can lead to costly migrations down the road. We've all heard the horror stories: teams forced into a six-month migration off a trendy NoSQL database back to PostgreSQL, or vice versa, all because the initial choice was based on hype rather than a rigorous analysis of the application's true needs.

The classic 'SQL for structured data, NoSQL for unstructured scale' is now a dangerous oversimplification.

The modern data landscape is a rich, complex ecosystem of relational, document, key-value, graph, and time-series databases, each optimized for specific workloads. Furthermore, the rise of cloud-native architectures, AI/ML applications, and the practice of polyglot persistence-using multiple databases within one system-means the decision is more nuanced than ever.

The goal is no longer to find one database to rule them all, but to build a deliberate strategy for data storage across your entire application portfolio.

This guide is for the solution architects, tech leads, and engineering managers standing at that critical juncture.

It's not a list of the 'top 10 databases'. Instead, it provides a durable, vendor-agnostic decision framework. We will equip you with the mental models, comparison criteria, and scoring checklists needed to dissect your application's requirements and map them to the right database technology.

By the end of this article, you will have a structured process to make a defensible, forward-looking database choice that aligns with your technical needs, team skills, and business objectives.

Key Takeaways

1. Framework Over Trends: The most critical mistake is choosing a database based on popularity or past experience alone.

   A structured decision framework that analyzes your specific workload, data model, and scalability requirements is essential to avoid costly future migrations.

2. It's a Spectrum, Not a Binary Choice: The 'SQL vs. NoSQL' debate is outdated. The modern landscape includes specialized databases (Graph, Time-Series, Vector) and hybrid approaches. The key is understanding the trade-offs between consistency, availability, scalability, and query flexibility for your use case.
3. Consider Total Cost of Ownership (TCO): The sticker price of a database (or lack thereof for open source) is a small fraction of its true cost. Operational overhead, developer training, monitoring, and the cost of downtime or poor performance must be factored into the decision.
4. Failure is an Option (and You Should Plan for It): The most common failure patterns include 'resume-driven development' (choosing a trendy technology), underestimating operational complexity, and forcing a single database to solve all problems (monolithic persistence).
5. Polyglot Persistence is the New Norm: For complex applications, the best architecture often involves using multiple database types, each suited to a specific task (e.g., PostgreSQL for transactions, Elasticsearch for search, Redis for caching). This is known as polyglot persistence.

The Decision Scenario: Beyond 'SQL vs. NoSQL'

The pressure to choose a database often arrives early in a project's lifecycle, frequently under tight deadlines.

The decision falls to a solution architect or tech lead who must balance immediate development speed with long-term strategic goals. The stakeholders are many: developers want a database that is easy to use and doesn't get in their way; operations teams want a system that is stable, monitorable, and easy to manage; and the business wants a solution that is cost-effective and can scale as the product grows.

These competing priorities create a complex decision space where there is rarely a single, perfect answer.

The classic dilemma has been framed as SQL versus NoSQL. SQL databases, the relational stalwarts like PostgreSQL and MySQL, offer the safety of ACID transactions, data integrity, and a powerful, standardized query language.

They are the bedrock of systems requiring strong consistency, such as financial or e-commerce transaction engines. Their weakness has historically been the difficulty of horizontal scaling (scaling out across many machines), leading teams to scale vertically (buy bigger, more expensive servers).

This created an opening for NoSQL databases like MongoDB, Cassandra, and DynamoDB, which were designed from the ground up for massive horizontal scalability, schema flexibility, and high availability, often at the expense of the strict consistency guarantees found in their relational counterparts.

However, this binary view is now obsolete. The lines have blurred significantly. Modern relational databases like PostgreSQL have incorporated features to handle semi-structured data (like JSONB) with impressive performance, while many NoSQL databases have added stronger transactional capabilities.

More importantly, the ecosystem has expanded dramatically. We now have specialized databases that are orders of magnitude better for specific problems: graph databases (Neo4j) for highly connected data, time-series databases (InfluxDB, TimescaleDB) for metrics and events, and search databases (Elasticsearch) for text search and analytics.

The relevant question today is not 'SQL or NoSQL?', but 'Which database model, or combination of models, is right for this specific workload?'

This shift requires a more sophisticated approach. Instead of picking a single general-purpose database, modern architecture often embraces polyglot persistence, the practice of using different database technologies for different parts of an application.

For example, an e-commerce site might use a relational database for orders, a document database for the product catalog, a search engine for product discovery, and a key-value store for user session data. This strategy optimizes performance and scalability by matching the tool to the job, but it also introduces complexity in data management and operations.

Therefore, the decision is not just about a single database, but about the overall data architecture strategy.

A Modern Taxonomy of Database Models

To make an informed choice, you first need to understand the menu of options. Thinking about databases in terms of their underlying data model is the most effective way to reason about their strengths and weaknesses.

The data model dictates how data is organized, stored, and manipulated, which in turn determines the types of queries and access patterns the database excels at. While there are dozens of specialized databases, most fall into one of the following fundamental categories.

Relational (SQL): The most mature and widely understood model. Data is organized into tables (relations) with predefined schemas, consisting of rows and columns.

Relationships between tables are enforced via foreign keys, ensuring data integrity. They are the default choice for applications requiring strong transactional guarantees (ACID) and complex queries with joins across multiple tables.

Examples: PostgreSQL, MySQL, Microsoft SQL Server, Oracle.
Ideal Use Case: Financial systems, inventory management, any application where data consistency and integrity are paramount.

Document: These databases store data in flexible, JSON-like documents. There is no rigid, predefined schema, allowing developers to evolve their data structures easily.

Data for a single entity (e.g., a user and all their profile information) is often stored together in one document, which makes reads very fast for a given key. They are a popular choice for web applications, content management, and product catalogs.
Examples: MongoDB, Couchbase, Amazon DynamoDB (which also has key-value characteristics).
Ideal Use Case: User profiles, product catalogs, content management systems where the data structure evolves over time.

Key-Value: The simplest model, where data is stored as a collection of key-value pairs. Think of it as a massive, persistent dictionary or hash map.

They are incredibly fast for simple lookups, reads, and writes by a known key, but offer little flexibility for complex querying. They are often used for caching, session management, and real-time leaderboards.
Examples: Redis, Memcached, Amazon DynamoDB.
Ideal Use Case: Caching, session stores, real-time bidding, leaderboards.

Wide-Column (or Column-Family): These databases store data in tables, rows, and columns, but the names and format of the columns can vary from row to row in the same table.

They are designed to store massive amounts of data distributed across many commodity servers. They excel at write-heavy workloads and queries over large datasets that only touch a subset of columns.
Examples: Apache Cassandra, Google Bigtable, Apache HBase.
Ideal Use Case: IoT sensor data, logging and event data, large-scale analytics where write throughput is critical.

Graph: Optimized for storing and navigating complex relationships. Data is modeled as nodes (entities) and edges (relationships), each of which can have properties.

Graph databases are exceptionally good at answering questions like 'what are the common friends of user A and user B?' or 'what is the shortest path from point X to point Y?'. These queries are often slow and complex in relational databases.
Examples: Neo4j, Amazon Neptune, ArangoDB.
Ideal Use Case: Social networks, fraud detection, recommendation engines, knowledge graphs.

Time-Series: Purpose-built to handle time-stamped data, such as server metrics, application performance monitoring (APM), IoT sensor data, or financial market data.

They are highly optimized for high-volume writes and queries that aggregate data over time windows (e.g., 'calculate the average CPU usage for server X over the last hour').
Examples: InfluxDB, TimescaleDB, Prometheus.
Ideal Use Case: DevOps monitoring, IoT applications, real-time analytics, financial trading systems.

The Decision Artifact: A Database Comparison Matrix

Theoretical knowledge is useful, but decisions are made by comparing concrete trade-offs. This matrix serves as a scannable artifact to guide your thinking.

For each primary database model, it evaluates them against the critical criteria that impact your application's architecture, performance, and operational lifecycle. Use this table not as an absolute scoring system, but as a conversation starter with your team to clarify which criteria matter most for your specific project.

The key to using this matrix is to first rank the importance of each criterion (the rows) for your application. Is query flexibility more important than raw write throughput? Is zero operational complexity a hard requirement, or do you have a skilled DevOps team? Once you have your priorities straight, the right database category will often become much clearer.

Here is a breakdown of the criteria used in the matrix:

1. Data Model: The fundamental structure for storing data (e.g., tables, documents, graphs).
2. Primary Workload: The type of operations the database is optimized for (e.g., transactional, analytical, search).
3. Scalability Model: How the database handles increased load. 'Vertical' (scale-up) means adding more power (CPU, RAM) to a single server. 'Horizontal' (scale-out) means adding more servers to a cluster.
4. Consistency Guarantees: The trade-offs between data consistency and system availability, often discussed in the context of the CAP theorem (Consistency, Availability, Partition Tolerance). Strong consistency (ACID) is typical for relational databases, while many NoSQL systems offer tunable or eventual consistency (BASE).
5. Query Flexibility: The ability to run ad-hoc, complex queries against the data. SQL provides the highest flexibility, while simple key-value stores provide the least.
6. Operational Complexity: The effort required to set up, configure, maintain, and scale the database. This is a crucial factor often overlooked in initial decisions.

Common Failure Patterns: Why Good Teams Choose Bad Databases

Technical merit alone doesn't guarantee a successful outcome. Some of the most costly mistakes in database selection stem from organizational dynamics and cognitive biases, not a misunderstanding of the technology itself.

Intelligent, capable teams fall into these traps every day. Recognizing these patterns is the first step to avoiding them.

Failure Pattern 1: Resume-Driven Development (RDD)

This is perhaps the most insidious failure mode. It occurs when a team, or an influential member of a team, chooses a technology to add to their resume rather than because it's the best fit for the problem.

The allure of working with the 'latest and greatest' database can overshadow a pragmatic analysis of the project's actual needs. A team building a simple CRUD application for 50 internal users does not need a complex, web-scale distributed database, yet RDD can lead them there.

The consequence is a system that is over-engineered, difficult to operate, and requires a specialized skillset that the company may struggle to hire for, all for a problem that a simple PostgreSQL instance could have solved in a fraction of the time and cost.

Failure Pattern 2: The 'One Database to Rule Them All' Fallacy

This failure pattern is the opposite of polyglot persistence. It happens when an organization becomes so comfortable with a single database (e.g., Oracle, SQL Server, or even MongoDB) that they try to force it to solve every problem.

An engineering team might be highly proficient in relational databases and, when faced with a problem that screams for a graph database (like fraud detection), they will spend months building a convoluted schema with dozens of join tables and recursive queries. The solution might 'work,' but it will be slow, brittle, and incredibly difficult to maintain compared to using the right tool for the job.

This approach ignores that modern databases are specialized tools. You wouldn't use a screwdriver to hammer a nail, yet teams do the digital equivalent all the time out of familiarity or an organizational mandate to standardize.

Failure Pattern 3: Ignoring Total Cost of Ownership (TCO)

Many teams are seduced by the zero-dollar price tag of open-source databases without fully accounting for the Total Cost of Ownership.

TCO includes not just licensing, but also the cost of hardware/hosting, operational overhead (monitoring, backups, patching, upgrades), developer training, and the business cost of potential downtime or performance issues. Choosing a powerful but complex distributed database like Cassandra requires a significant investment in operational expertise.

If you don't have a dedicated DevOps or SRE team with experience running such systems, you are signing up for a world of pain. The 'free' database can quickly become the most expensive part of your infrastructure when you factor in the engineering hours spent debugging, tuning, and recovering it at 3 a.m.

Failure Pattern 4: Premature Optimization for 'Web Scale'

A team might read about the architecture of Netflix or Uber and decide they need a database that can handle billions of transactions per day, even though their product has yet to find its first 100 users.

This leads to choosing highly scalable but complex NoSQL systems when a simple, vertically scalable relational database would suffice for the foreseeable future. The trade-off is often a loss of transactional integrity, query flexibility, and developer productivity for a level of scale the application may never reach.

A better approach is to choose a database that solves today's problems well but has a clear scaling path for the future. For example, starting with a managed PostgreSQL instance and knowing you can later migrate to a distributed SQL variant if and when you need to.

The Decision Checklist: A Scoring Framework for Your Use Case

To move from a comparison matrix to a concrete decision, you need to apply the criteria to your specific project.

This checklist provides a structured way to do just that. For each question, rate its importance to your project on a scale of 1 (not important) to 5 (critically important).

Then, evaluate your candidate databases against these prioritized requirements. This process forces you to be explicit about your trade-offs.

The goal is not to find a database that scores a perfect 5 on every metric, as such a database does not exist. The goal is to find the database that scores highest on the metrics that are most important to you.

According to Developers.dev analysis of over 3,000 projects, incorrect database selection is a primary driver of technical debt, often leading to a 30-40% increase in maintenance costs within two years.

Database Selection Scoring Checklist

1. Define Your Data Model & Structure (Importance: 5)

   1. Is your data highly structured with clear relationships (e.g., orders and customers)? (Favors Relational)
   2. Is your data semi-structured or does the schema change frequently? (Favors Document)
   3. Is the core of your data about connections and relationships? (Favors Graph)
   4. Is all your data tied to a timestamp? (Favors Time-Series)
   5. How well does each candidate DB's model fit your data?

2. Define Your Primary Workload (Importance: 5)

   1. Is the application read-heavy, write-heavy, or balanced?
   2. Are transactions involving multiple records (e.g., transferring funds) a core requirement? (Favors Strong Consistency/ACID)
   3. Do you need to perform complex analytical queries and aggregations? (Favors Relational or Columnar)
   4. Are most operations simple lookups by a primary key? (Favors Key-Value/Document)
   5. How well is each candidate DB optimized for your primary workload?

3. Define Your Scale & Performance Needs (Importance: 5)

   1. What is your expected data volume in 1 year? 3 years?
   2. What are your latency requirements (e.g., p99 response time
   3. What is your expected throughput (e.g., requests per second)?
   4. Do you need to scale reads and writes independently?
   5. Is horizontal scaling a day-1 requirement, or can you start with vertical scaling?
   6. Does each candidate DB have a credible path to meet your scale requirements?

4. Define Your Consistency Requirements (Importance: 5)

   1. Is it acceptable for a user to see slightly stale data for a few seconds? (Allows for Eventual Consistency)
   2. Does a transaction absolutely have to be all-or-nothing? (Requires Strong Consistency/ACID)
   3. This is a direct application of the CAP Theorem: in the face of a network partition, do you choose to fail requests (prioritizing Consistency) or return potentially stale data (prioritizing Availability)?
   4. Where does each candidate DB stand on the CAP theorem spectrum, and does it match your business needs?

5. Assess Your Team's Skills & Ecosystem (Importance: 5)

   1. What database technologies does your team already know well?
   2. How steep is the learning curve for a new technology?
   3. How large is the community? How good is the documentation?
   4. What does the hiring pool look like for this technology?
   5. Are there good libraries and tools for your chosen programming language?
   6. What is the 'human cost' of adopting each candidate DB?

6. Calculate Total Cost of Ownership (TCO) (Importance: 5)

   1. What are the licensing and/or managed service costs?
   2. What are the underlying infrastructure costs (servers, storage, network)?
   3. What is the estimated operational cost in terms of engineering hours for maintenance, monitoring, and troubleshooting?
   4. What is the cost of a potential outage for this system?
   5. What is the fully-loaded, 3-year TCO for running each candidate DB at your expected scale?

Making the Call: Clear Recommendations by Persona

The 'right' answer depends heavily on who you are and what constraints you operate under. The optimal choice for a seed-stage startup is often different from that of a large enterprise.

Here are some pragmatic recommendations tailored to different technical personas and their typical environments.

For the Startup CTO/Founder

Your primary constraints are time, money, and the need to iterate quickly. You are optimizing for speed of development and flexibility to pivot.

Your user base is small, and your scale problems are, for now, hypothetical. Don't over-engineer.
Recommendation: Start with a single, managed, general-purpose database that offers a good balance of features and flexibility.

A managed PostgreSQL (like Amazon RDS or Google Cloud SQL) is an outstanding choice. It's reliable, feature-rich, and its support for JSONB gives you a degree of schema flexibility, acting as a 'good enough' document store within your relational database.

Alternatively, a managed Document DB like MongoDB Atlas can be excellent if your data is naturally document-centric and you value schema flexibility above all else. The key is to choose one and move fast. Let a future version of your company worry about 'web scale'.

For the Enterprise Architect

Your world is defined by complexity, integration, governance, and risk management. You are designing systems that must interact with dozens of other legacy and modern applications, adhere to strict security and compliance standards, and be maintainable for a decade or more.

You are optimizing for stability, security, and long-term viability.
Recommendation: Embrace polyglot persistence as a core strategy. There is no 'one database' for the enterprise. Your job is to define a portfolio of blessed, supported database technologies and guide teams on when to use each.

This portfolio should include a rock-solid Relational DB (like Oracle or PostgreSQL) for core systems of record, a scalable Document DB (like MongoDB) for customer-facing applications, a Search DB (like Elasticsearch) for discovery and analytics, and potentially a Graph DB (like Neo4j) for identity or fraud. The key is to build a 'paved road' with well-defined patterns for data integration, security, and operations for each supported database.

For the Tech Lead on a High-Scale Project

You are tasked with building a specific service that has demanding performance and scalability requirements. You might be building a real-time bidding platform, an IoT data ingestion pipeline, or a social media feed.

You are optimizing for throughput, low latency, and fault tolerance at a massive scale.
Recommendation: This is where specialized databases shine. Your choice must be driven entirely by the workload. If you're handling massive write volumes of time-stamped data, a Time-Series DB like TimescaleDB or a Wide-Column Store like Cassandra is likely the right choice.

If you are building a recommendation engine, a Graph DB is non-negotiable. If you need lightning-fast lookups for a massive dataset, a Key-Value or in-memory store like Redis is your answer.

You must deeply understand the trade-offs of the CAP theorem and choose a database that aligns with your service's specific needs for consistency and availability.

Beyond the Decision: Implementation and Governance

Choosing the database is a critical milestone, but it is not the end of the journey. The value of a good decision can be completely eroded by poor implementation and a lack of ongoing governance.

Once the technology is selected, the focus must shift to establishing the patterns, processes, and tools required to use it effectively and sustainably throughout the application's lifecycle. This is where architectural theory meets operational reality.

A crucial first step is investing in data modeling. This might seem counterintuitive for schema-less NoSQL databases, but it's actually even more important.

While the database itself doesn't enforce a schema, your application code implicitly defines one. Without a deliberate approach to data modeling, you end up with a chaotic mix of document structures that becomes impossible for developers to reason about.

The principle of 'schema-on-read' shifts the burden of managing structure from the database to the application developer, and without discipline, this leads to bugs and maintenance nightmares. Your team should agree on and document the canonical shapes of your data entities, regardless of the underlying database technology.

Next, monitoring and observability must be a day-one consideration. Every database, whether a managed service or self-hosted, is a potential source of failure and performance bottlenecks.

Your team needs a deep understanding of the key health metrics for the chosen database. This goes beyond basic CPU and memory usage. It includes metrics like query latency (average, p95, p99), throughput (reads/writes per second), replication lag, connection counts, and cache hit rates.

Setting up dashboards and alerts for these key performance indicators is not an optional add-on; it is a fundamental requirement for running a reliable production system. This is a core competency of our Site-Reliability-Engineering / Observability Pod.

Finally, always have a plan for future migration. It's an uncomfortable truth, but the database you choose today may not be the right database in five years.

The business may pivot, the scale of your data may grow exponentially, or a new technology may emerge that is 10x better for your workload. Building your application with this eventuality in mind can save you from a world of pain. This means creating a clean separation between your application's business logic and its data access layer.

Using a repository pattern or similar abstraction can help isolate database-specific code, making it easier to swap out the underlying storage engine in the future. While a full migration is always a significant undertaking, a well-architected application makes it a feasible engineering project rather than an impossible, multi-year rewrite.

Conclusion: A Framework for Deliberate Decisions

The journey to selecting the right database is not about finding a mythical 'best' technology, but about executing a disciplined process to find the best fit for your unique context.

The wrong choice, often made hastily or based on trends, introduces a hidden tax on every future engineering effort. In contrast, the right choice acts as a multiplier, enabling teams to build features faster, scale more gracefully, and operate with confidence.

This decision deserves the rigor and deliberation of any foundational architectural choice.

By adopting a structured framework, you transform the decision from a subjective debate into an objective analysis.

The key actions are clear:

1. Prioritize Your Requirements: Use the scoring checklist to force clarity on what truly matters: is it write throughput, transactional consistency, or operational simplicity? Be honest about your trade-offs.
2. Understand the Models: Move beyond the SQL vs. NoSQL binary. Understand the fundamental strengths of relational, document, key-value, graph, and time-series models to match the tool to the workload.
3. Calculate the True Cost: Look beyond the license fee to the Total Cost of Ownership. Factor in the operational burden and the required skillset of your team. A 'free' database that your team can't operate is a costly liability.
4. Beware of Failure Patterns: Actively guard against resume-driven development, premature optimization, and the fallacy of a one-size-fits-all solution. Acknowledging these biases is the first step to overcoming them.
5. Plan for Evolution: Architect your application with a clean data access layer. The database you choose today may not be the one you need tomorrow. A little foresight in abstraction can prevent a painful future rewrite.

Ultimately, selecting a database is an act of predicting the future of your application. By grounding that prediction in a framework of clear requirements, objective comparisons, and an honest assessment of your team's capabilities, you can make a decision that will serve as a stable foundation for growth, not a source of technical debt.

About Developers.dev

This article was written and reviewed by the expert team at Developers.dev. With a CMMI Level 5 certification and over 3,000 successful projects, our teams have deep, hands-on experience in architecting, implementing, and managing high-performance data systems for clients across the globe.

Our custom software development and staff augmentation PODs, including specialized Big-Data and Python Data-Engineering teams, help companies like yours navigate these critical technology decisions every day.

Frequently Asked Questions

Can I use more than one database in my application?

Yes, absolutely. This is a common and often recommended practice called 'polyglot persistence'. The core idea is to use the right tool for the right job.

For example, you might use a relational database like PostgreSQL for your core transactional data that requires ACID compliance, a search engine like Elasticsearch for product search functionality, and a key-value store like Redis for caching user sessions. While this approach adds operational complexity, it allows you to optimize each part of your application for performance and scale.

The key to success is to have a clear strategy for data integration and management between the different stores.

Is SQL or NoSQL better for performance?

This question is unanswerable without more context. 'Performance' is not a single metric. A NoSQL key-value store like Redis will offer unparalleled performance for simple key-based lookups, far outperforming a relational database.

However, if your workload involves complex queries with multiple joins and aggregations across different datasets, a well-tuned SQL database like PostgreSQL will almost certainly be more performant than trying to simulate those joins in application code with a NoSQL database. The right question is not 'which is faster?', but 'which is faster for my specific access patterns and workload?'.

How does using a serverless architecture affect my database choice?

Serverless architectures, like those using AWS Lambda or Google Cloud Functions, have a significant impact on database selection.

Because serverless functions are ephemeral and can scale to a massive number of concurrent executions, they can easily overwhelm a traditional database with connection requests. This pushes you towards databases that are designed to handle this kind of workload. Ideal choices are often fully managed, serverless databases that offer an HTTP-based data API (avoiding connection pooling issues) and scale automatically with demand.

Examples include Amazon DynamoDB, Google's Firestore, and serverless offerings of relational databases like Amazon Aurora Serverless.

When should I seriously consider a graph database?

You should seriously consider a graph database when the relationships between your data points are as important, or even more important, than the data points themselves.

If your queries frequently involve phrases like 'people who know people who...', 'path from A to B', or 'detecting circular dependencies', you have a graph problem. While you can model these relationships in a relational database using join tables, the query performance degrades exponentially as the depth of the relationships and the size of the dataset grow.

A native graph database is optimized for these types of traversal queries and will be orders of magnitude faster. Common use cases include social networks, fraud detection (finding rings of fraudulent users), and recommendation engines ('users who bought this also bought...').

What is the CAP Theorem and why does it matter for my choice?

The CAP Theorem, formulated by Eric Brewer, states that a distributed data store cannot simultaneously provide more than two of the following three guarantees: Consistency, Availability, and Partition Tolerance.

1. Consistency: Every read receives the most recent write or an error.
2. Availability: Every request receives a non-error response, without the guarantee that it contains the most recent write.
3. Partition Tolerance: The system continues to operate despite network partitions (i.e., messages being dropped between nodes).

In modern distributed systems, network partitions are a fact of life, so Partition Tolerance (P) is generally considered non-negotiable.

This means that in the event of a network failure, you must make a trade-off between Consistency (CP) and Availability (AP). A CP system (like many traditional databases) will return an error or time out to avoid returning stale data. An AP system (like many NoSQL databases) will respond with the best data it has, even if it might be stale.

Understanding whether your application can tolerate stale data (e.g., social media likes) or absolutely requires the most recent data (e.g., a bank balance) is critical to choosing a database with the right trade-offs.