SQL vs NoSQL: which database should a business application start with?

Someone chooses a database in the first weeks of a project, and the company lives with that choice for a decade. The pitch for NoSQL usually arrives with two claims: relational databases cannot scale, and flexible schemas move faster. Both claims were stronger a decade ago than they are today, and picking on the strength of them is how small companies end up running infrastructure built for a problem they do not have.

SQL vs NoSQL: which should a business application start with?

Start with a relational database. For the customers, orders, invoices, inventory and approvals that most business software handles, a relational database enforces the rules and answers new questions without redesign. Choose NoSQL when you can name a specific workload that a relational database handles badly.

A relational (SQL) database stores data in tables of rows and columns, links tables through shared keys, and is queried with the SQL language. NoSQL is an umbrella term for databases that do not use that table model. AWS lists key-value, document, graph, in-memory and search databases as NoSQL types, and the differences between them are larger than the differences inside the SQL family.

ACID means a group of changes either all succeed or all fail, and nobody sees a half-finished state. A schema is the declared structure of the data: which fields exist and what type each one holds.

How do the data model and schema differ?

A relational database makes you decide the structure first, and that discipline is the main benefit for business data. If an invoice must belong to a customer, the database can refuse an invoice with no customer. The rule lives in one place instead of in every application that writes invoices.

A document database stores each record as a self-contained document. MongoDB's data modeling guide states the principle directly: data that is accessed together should be stored together. It also describes the flexibility: documents in one collection do not need the same fields, and you can add fields without a schema migration. MongoDB adds that you can enforce a fixed structure with schema validation if needed.

That flexibility helps when records genuinely differ in shape, such as product listings with different attributes per category. It hurts when the shape is not actually flexible. An order always has a customer, line items and a total, so a flexible schema just moves enforcement into application code, where every team has to remember it.

Do NoSQL databases support transactions?

Yes. The belief that NoSQL means no transactions is out of date for two of the best-known products.

MongoDB's manual says it supports multi-document ACID transactions, and that they are available in all supported MongoDB versions. The same page adds a caution: in most cases a distributed transaction costs more than a single-document write, and transactions should not replace good schema design. MongoDB's own advice is to embed related data so that fewer transactions are needed.

Amazon DynamoDB also offers ACID transactions. A single write transaction can group up to 100 actions on up to 100 items in the same AWS account and Region. The aggregate size limit is 4 MB. DynamoDB performs two underlying reads or writes for every item in a transaction, one to prepare and one to commit, and you pay for both. Transactions cannot be performed using indexes, and in global tables the guarantees apply only within the Region where the write was made.

The honest summary: transactions exist, but they are an added feature with limits on a system designed around single records. In a relational database they are the default, and the limits are far looser. If your application regularly changes several kinds of records together, such as an order, its stock levels and a ledger entry, that fit favors relational.

Can SQL databases scale?

They scale further than their reputation, and the way they scale is well understood. A single database server has a ceiling, and the order in which companies hit it is predictable.

1. Read replicas. A read replica is a read-only copy of the database. AWS describes using replicas to scale beyond the capacity of a single instance for read-heavy workloads, and to run business reporting away from production. Replicas update asynchronously, so they can lag slightly.
2. Partitioning. Splitting one large table into smaller physical pieces. The PostgreSQL documentation gives a rule of thumb that a table benefits when its size exceeds the physical memory of the database server.
3. Sharding. Spreading data across several database servers. Notion described (in a post dated October 6, 2021) splitting its Postgres data into 480 logical shards spread across 32 physical databases. Meta's engineering team wrote in 2013 that TAO, its social graph store, partitions its data into hundreds of thousands of shards backed by MySQL.

Sharding is real work, and Notion's post notes that distributed joins are expensive and transactions are typically limited to a single host. MongoDB's own documentation makes the same point about its approach: spreading data over many servers can cost less than one high-end machine, but the trade-off is increased complexity in infrastructure and maintenance. NoSQL systems that spread data automatically remove some of that work and add constraints elsewhere.

A reasonable rule for a company of 20 to 200 people: the write volume of your internal systems, customer portal and operational data very rarely exceeds what one properly sized, well-indexed database server can handle. When it does, read replicas come before anything more drastic.

Can PostgreSQL handle flexible, document-style data?

Yes, and this removes the most common reason to choose a document database. PostgreSQL's jsonb type stores JSON in a decomposed binary format. The PostgreSQL 18 documentation says jsonb is significantly faster to process than plain JSON, supports indexing, and that most applications should prefer jsonb unless they have quite specialized needs. Its GIN index type can search for keys or key and value pairs across a large number of jsonb documents.

The practical pattern: keep the stable core of your data in ordinary columns, and put the variable part, such as product attributes or form responses, in a jsonb column on the same row. You get flexibility where you need it and relational rules everywhere else, in one database with one backup.

When does NoSQL earn its place?

NoSQL earns its place when a workload has a shape that tables handle awkwardly, and you can name it. Typical cases:

• Very high throughput on simple, key-based lookups. Session data, device telemetry or event streams where every request fetches or writes one item by its key, at a volume beyond one server.
• Caching. Redis describes itself as an in-memory data store used as a cache, among other roles. A cache in front of a relational database is one of the most common and least risky additions.
• Self-contained documents with genuinely varied shapes that are almost always read and written as a unit.
• Relationship-heavy questions such as connections between people, accounts or devices, where a graph database fits.
• Full-text search across large volumes of content, where a search engine beats database queries.

Each of these is a supporting role beside a relational system of record. Our guide to the types of databases covers the full list, including time-series, wide-column and vector databases.

Popularity is not proof, but it has practical weight for hiring and tooling. In the 2026 Stack Overflow Developer Survey, PostgreSQL ranked first among databases at 57.9%, MongoDB was at 19.0% and DynamoDB at 9.3%.

Illustrative example: Consider a 90-person building-supplies distributor commissioning a customer portal and an order system. A vendor proposes MongoDB because "orders vary a lot." Walking through the actual requirements, every order has a customer, a price list, line items, an approval and an invoice, and a stock change must succeed or fail together with the order. That is relational data with transactional rules. The team chooses PostgreSQL, stores the varying product specifications in a jsonb column, and adds a cache only if portal pages turn out to be slow. If the company later ingests sensor data from delivery trucks at high volume, that stream can go to a purpose-built store without disturbing the order system.

How do you decide between SQL and NoSQL?

Work through these questions in order.

1. Do changes touch several kinds of records together? If yes, choose relational.
2. Will the business keep asking new questions of the data, such as reports by region, customer type and month? If yes, choose relational. Joins answer unplanned questions cheaply.
3. Is the data mostly independent records read by key, at a volume beyond one server? Consider a key-value or wide-column store for that workload only.
4. Is the flexible part small? Use a jsonb column inside the relational database.
5. Do you already operate one of these systems well? Existing skill is a real input. A database your team can run and recover at 2 a.m. beats a theoretically better one nobody understands.

Whatever you choose, keep database access behind one layer of the application code and write down why you chose it. That makes a later change a project instead of a rewrite.

How Kastling approaches database choices

Database selection is part of the design work in Custom Solutions: internal tools, dashboards, portals and web or mobile applications built around how a business actually works. Kastling would start from the business records and rules involved, the questions people need answered and the existing systems the data must connect to, and then pick the simplest database that fits. Any added system would need a named reason and a named owner, and success measures would be agreed up front. For related decisions, see our guides to why PostgreSQL became the default database and what drives the cost of custom software.