Why I am still using simple SQL for most modern projects

Choosing Simplicity in an Age of Over-Engineering

In the modern web development landscape, there is a constant pressure to adopt the latest and greatest technologies. We are told that to build a scalable application, we need a distributed NoSQL database, a complex Object-Relational Mapper (ORM), and a dozen middleware layers just to fetch a user profile. However, at Redunx, we believe in innovation through simplicity. After years of navigating the shifting tides of backend architecture, I have found myself returning to a fundamental truth: simple, raw SQL is often the most powerful tool in a developer’s arsenal.

While many developers view SQL as a legacy technology, it is actually one of the most stable and performant standards in the industry. In this article, I want to share why I’ve moved away from heavy abstractions and why I continue to use simple SQL for the majority of my modern web projects.

The Problem with Modern Abstractions

ORMs were designed to bridge the gap between object-oriented programming and relational databases. On the surface, they seem like a dream come true. You can interact with your database using the same language you use for your application logic, and you don’t have to worry about the underlying syntax. But as projects grow, these abstractions often become more of a hindrance than a help.

The primary issue is the ‘leaky abstraction.’ Eventually, you will encounter a query that the ORM cannot handle efficiently. You’ll find yourself wrestling with complex syntax to perform a simple JOIN or, worse, the ORM will generate incredibly inefficient queries that slow your application to a crawl. By the time you’ve learned the specific quirks of a heavy ORM, you could have written a clean, optimized SQL query that is easier to read and maintain.

Avoiding the N+1 Query Trap

One of the most common performance killers in modern web applications is the N+1 query problem. This happens when an ORM fetches a list of items and then executes a separate query for each item to fetch its related data. While most ORMs have ‘eager loading’ features to prevent this, they are often opt-in and easily forgotten. When you write simple SQL, you are forced to think about how your data is structured and how it is being retrieved. A single, well-crafted JOIN is not only more performant but also much easier to debug than a series of hidden queries triggered by an abstraction layer.

Why Simple SQL Wins for Modern Projects

Sticking to simple SQL doesn’t mean you’re stuck in the past. It means you’re choosing a tool that offers unmatched transparency and control. Here are a few reasons why SQL remains my go-to choice:

• Universal Portability: SQL is a standard. If you learn PostgreSQL, moving to MySQL or SQLite is a minor adjustment. If you learn a specific ORM for a specific framework, that knowledge is often locked into that ecosystem.
• Longevity: Frameworks and libraries come and go. SQL has been the backbone of data management for decades. The code you write today in SQL is much more likely to be readable and functional ten years from now than code written using a trendy library.
• Performance Optimization: When you write raw queries, you have direct access to the database engine’s features. You can use indexes, views, and specific database functions to optimize your data retrieval without waiting for an ORM to support those features.
• Easier Debugging: When a query fails, you can copy the raw SQL and run it directly in your database console. There’s no ‘magic’ happening behind the scenes, making it much easier to identify bottlenecks or logic errors.

A Practical Approach to Using SQL

Using simple SQL doesn’t mean you should be concatenating strings and exposing your application to SQL injection. A practical, modern approach involves using ‘thin’ wrappers or query builders that provide security without the overhead of a full ORM. Tools like pg-promise for Node.js, sqlx for Rust, or even simple prepared statements in PHP and Python allow you to write raw SQL while handling parameterization safely.

How to Structure Your Data Access

To keep your project clean while using SQL, I recommend following a few simple organizational rules:

1. Create a Data Access Layer (DAL): Don’t scatter SQL queries throughout your business logic. Keep them in dedicated files or modules where they can be easily managed and updated.
2. Use Prepared Statements: Always use parameterized queries to protect against SQL injection. This is the golden rule of working with databases.
3. Keep Queries Readable: Use multi-line strings and proper indentation for your SQL. Just because it’s a string in your code doesn’t mean it should be a mess.
4. Log Your Queries: In your development environment, log the raw SQL being sent to the database. This provides instant feedback on what your application is actually doing.

When Simplicity Leads to Innovation

At Redunx, we believe that innovation happens when you remove the barriers between your ideas and your implementation. Overcomplicating your data layer with unnecessary technical layers doesn’t make your application ‘enterprise-grade’; it often just makes it slower and harder to maintain. By using simple SQL, you reduce the cognitive load on your team. You spend less time reading documentation for an abstraction layer and more time building features that provide value to your users.

Modern web development is already complex enough. Between frontend frameworks, deployment pipelines, and cloud infrastructure, there are plenty of places where complexity is unavoidable. Your database queries don’t have to be one of them. By embracing the power and simplicity of SQL, you can build faster, more reliable, and more maintainable applications that stand the test of time.

Conclusion

The next time you start a new project, resist the urge to automatically reach for the most complex tool available. Ask yourself if a simple SQL query could do the job better. More often than not, you’ll find that the ‘old’ way of doing things is actually the most innovative path forward. Simple SQL isn’t about being outdated; it’s about being practical, efficient, and focused on what truly matters: building great software without limits.