Choosing a database is one of the hardest decisions to change later. For most applications, though, the choice is simpler than the online debate suggests.

Relational (SQL) databases

PostgreSQL, MySQL and SQLite store data in tables with a defined schema and relationships between them. You query them with SQL.

  • Strong consistency and transactions, so related changes succeed or fail together.
  • Joins make it easy to combine related data, like users, orders and products.
  • A mature ecosystem of ORMs, tools and hosting.

NoSQL databases

NoSQL is an umbrella term for databases that do not use the relational table model:

  • Document stores such as MongoDB keep JSON-like documents, handy when records have varied shapes.
  • Key-value stores such as Redis are extremely fast for caching, sessions and counters.
  • Wide-column stores such as Cassandra handle huge write volumes across many servers.
  • Graph databases such as Neo4j make relationship-heavy queries easy, like social networks or recommendations.

A practical rule

Start with PostgreSQL unless you have a clear reason not to. It handles relational data well, supports JSON columns for flexible fields, and has extensions for full-text search and vector embeddings. Add a specialized store, like Redis for caching, when a specific need appears.

Questions to ask

  • How are you going to query the data most often?
  • Do you need transactions across multiple records?
  • How much data and traffic do you really expect in the next year?

An example: an online shop

Picture a small online store. Customers, orders, products and payments are tightly connected: an order belongs to a customer, contains products and must match a payment. If the payment step fails, the order shouldn’t half exist. That is exactly what relational databases and transactions are built for, so the core of the shop belongs in PostgreSQL or MySQL.

Around that core, other needs appear. Shopping carts and login sessions are read and written constantly and can be rebuilt if lost, which suits a key-value store like Redis. Product search with typo tolerance may move to a search engine. A “customers who bought this also bought” feature might eventually justify a graph database. None of that requires giving up the relational core.

The schema question

A common argument for document databases is that they are “schemaless”, so you can store anything without planning. In practice, the schema doesn’t disappear; it moves into your application code, which has to cope with every shape of record ever saved. That flexibility helps early on and when data really does vary, such as user-defined form fields. For data with a stable shape, an explicit schema catches mistakes that would otherwise surface months later as strange bugs.

Scaling myths

NoSQL databases were popularized by companies operating at enormous scale, and for a while “SQL doesn’t scale” was common wisdom. For the vast majority of apps, it isn’t true. A single well-indexed PostgreSQL server handles a large amount of traffic, read replicas spread out read-heavy loads, and managed services take care of backups and failover. Distributed databases make sense when you truly outgrow one machine or need to write data in several regions at once, but they bring trade-offs in consistency and complexity that are worth avoiding until you need them.

Before you decide

Write down your five most common queries and try them against each candidate with realistic sample data. How the database handles your actual access patterns tells you far more than any general comparison.

What we think

For the vast majority of new applications, PostgreSQL is the right starting point. It handles relational data, flexible JSON fields and full-text search well, and it is easy to hire for and host.

Reach for a specialized database when you hit a specific problem it solves better, such as caching, huge write volumes or graph queries, not because it sounds more modern. Most teams that regret their database choice picked it for scale they never reached.