SQL Databases (Relational)

SQL databases are relational databases with a strictly defined schema, emphasizing data consistency, transactions, and relationship integrity. Data is stored in tables with relationships and managed using the SQL language. Typical examples include PostgreSQL, MySQL, and MariaDB.

✅ When is it appropriate

SQL databases are an excellent choice if most of the following apply:

the data has a clear structure and relationships
you need strong transactions (ACID)
data consistency is critical
the system handles orders, payments, or inventory states
data volume is predictable or grows gradually
the team is already familiar with SQL and relational modeling, and there is no compelling technical reason to use something else

SQL databases enforce rules at the database level: a foreign key prevents saving an order with a non-existent customer, a unique constraint prevents duplicate records, and a transaction ensures that a payment deduction and order creation either both succeed or both fail.

❌ When is it NOT appropriate

SQL databases may not be ideal if:

the data is very flexible or unstructured
the schema changes frequently or significantly
write throughput has outgrown what a single server can handle and you need to distribute writes across many nodes
you are working with massive volumes of events or logs
users in different geographic regions all need to write data locally with no noticeable latency, which requires a globally distributed write architecture that most SQL databases do not support natively

SQL databases scale writes vertically by upgrading the server, which has a ceiling. When you hit that ceiling or need to spread writes across multiple geographic locations, you will need to redesign the architecture or switch to a database built for horizontal distribution.

👍 Advantages

strong data consistency
support for transactions (ACID)
clear and readable data structure
robust support for relationships and integrity constraints
vast ecosystem of tools
long-term stability and proven reliability

👎 Disadvantages

changing the table structure requires a migration that must be planned and run against the live database, which adds overhead during rapid iteration
more complex horizontal scaling
JOINs can be performance-intensive
a single write node becomes a bottleneck when the number of concurrent writes exceeds what one server can handle
less flexible for unstructured data

🛠️ Typical use cases

web and backend applications
e-commerce systems
financial and accounting systems
CRM and ERP systems
internal enterprise applications
most common business applications

⚠️ Common mistakes (anti-patterns)

adding too many tables and relationships for data that could be stored more simply, making queries harder to write and slower to run
splitting data into too many small tables to eliminate all redundancy, resulting in queries that require many JOINs and become slow when the dataset grows
not adding indexes on columns used in WHERE or JOIN clauses, causing the database to scan every row in the table for every query as data grows
trying to handle analytical workloads on a transactional database
adding caching layers, partitioning, or replication before the application is even under real load, solving problems that do not yet exist

Missing indexes are the most common reason SQL queries slow down as data grows. Over-normalizing the schema causes many JOINs on every query. Running heavy analytical reports against the same database that serves live users can cause response time spikes for all users.

💡 How to build on it wisely

Recommended approach:

Start with a simple relational model.
When queries become slow, identify the most frequently executed queries using the database's query log or slow-query log, then add indexes on the columns those queries filter or join on.
Use indexes and transactions wisely.
If you hit limits, consider:
- read replicas
- caching
- supplementing with a NoSQL database

SQL is the right default for most applications. The signal to look elsewhere is when write throughput genuinely saturates a single server or when you need to store large volumes of schema-free data such as event logs or user activity. For everything else, invest in proper indexing and query tuning before reaching for a different database type.

Feedback & Sharing

Give us your thoughts on this page, or share it with others who may find it useful.

Share with your network:

Feedback

Found this helpful? Let me know what you think or suggest improvements 👉 Contact me.