Two broad styles
Databases are often sorted into two camps. SQL databases are relational: they store data in tables with rows and columns and are queried with Structured Query Language. NoSQL databases are everything else, a family of systems that use other ways to organize data. The name is sometimes read as “not only SQL,” and it describes a loose group, not a single technology.
Neither style is better in general. Each makes some things easy and others harder, and many real systems use both.
How SQL databases work
In a relational database, the structure comes first. You define tables, the columns in each one and their types, and how tables relate through keys. This blueprint is called a schema. Data that does not match the schema is rejected.
Strengths often associated with SQL databases:
- Clear structure and checks. The database can enforce rules such as “every order must belong to a real customer.”
- Joins. Queries can combine several tables, for example matching orders to customers, without copying information around.
- Transactions. Groups of changes succeed or fail together, which matters for things like payments and inventory.
- Mature tooling. SQL has been used for decades, so there is a lot of documentation, skills and supporting software.
Typical limits: changing the schema on a very large, busy table can be slow or disruptive, and scaling one database across many machines is harder than scaling simple lookups, though modern products offer ways to do it. The basics of tables and keys are covered in the introduction to how databases store information.
The main kinds of NoSQL databases
NoSQL systems each optimize for a particular data shape.
Document databases store self-contained records, usually in a JSON-like format. A user profile with a list of addresses and preferences can live in one document, with no need to split it into several tables. Different documents in the same collection may have different fields.
Key-value stores are like a giant dictionary: you give a key and receive a value. They are very quick for simple lookups and are often used for caches and session data.
Wide-column stores group data into column families and are designed to spread huge amounts of data across many servers.
Graph databases store items and the relationships between them directly, which suits questions like “who is connected to whom” in social networks or recommendation systems.
Time-series and search databases are further specialized types. They focus on timestamped readings, such as those from IoT devices, or on text search, respectively.
Key differences
| Question | SQL (relational) | NoSQL (varies by type) |
|---|---|---|
| Structure | Fixed schema defined up front | Often flexible or schema-on-read |
| Relationships | Joins across tables | Often embedded in documents or handled by the application |
| Transactions | Long-established strong support | Varies; many offer limited or newer support |
| Scaling | Traditionally up (bigger machine), with out options | Often designed to scale out across servers |
| Query language | Standard SQL, with dialect differences | Differs by product |
Treat this table as a generalization. Modern products blur the lines: some relational databases store JSON documents, and some NoSQL databases now support SQL-like queries and transactions.
Consistency and the trade-offs behind scaling
When data is copied across many servers, the system must decide what to do if copies disagree briefly. Some systems prioritize that everyone sees the latest value immediately (strong consistency). Others allow short delays, called eventual consistency, in return for speed and availability. For a social media like counter, being a few seconds behind may not matter. For a bank balance, it usually does. This is a spectrum, and good products let you tune it.
When each tends to fit
A relational database often suits:
- orders, payments, accounting and inventory, where accuracy and relationships matter
- data with a stable shape and many cross-references
- reporting needs, where people ask varied questions of the data
A NoSQL database may suit:
- content with varying fields, such as product catalogs with very different attributes
- very high volumes of simple reads and writes, such as caching or session storage
- relationship-heavy exploration (graph) or large streams of sensor readings (time-series)
- fast-changing projects where the data shape is still being worked out
Many applications combine them: a relational database for the account and billing records, a key-value cache to speed up pages, and a search engine for text queries.
Common myths
- “NoSQL means no structure.” Data still has a shape, but the application, instead of the database, may be responsible for it.
- “SQL cannot scale.” Many large services run on relational systems, though scaling takes planning.
- “NoSQL is newer, so it is better.” Newer is not the same as a better fit.
- “You must pick one.” Mixed setups are common.
Related ideas
Where the data goes after it is stored is another question. Organizations often copy data from operational databases into a data warehouse for reporting, or into data lakes for raw, mixed material. The shape of the data, whether neat rows or free text, also drives the choice, as discussed in the comparison of structured and unstructured data. Applications usually talk to either style through an API behind the scenes, so users never see which one is in use.
Making a choice
Starting with the data and the questions you need to answer is more reliable than starting with a trend. How often does the data change? Does it have clear relationships? How much accuracy is required? What does your team already know how to run? For a small project, a widely used relational database is often a safe default, and moving to something specialized can wait until a real need appears.