Free tools Windows power users keep installed
One-click scans. No signup required.
SQL is not about to disappear, but it can be a poor fit for some workloads. Its friction shows up when data is distributed across regions, applications repeatedly translate between rows and objects, or the data is more naturally treated as documents, graph relationships, streams, or search indexes. Those are reasons to question a design—not proof that every SQL database should be replaced. Peter Wayner’s September 8, 2025 InfoWorld feature makes the case against SQL; the practical question is which of its criticisms apply to your system.
1. Tables can make distributed scaling harder
Relational tables do not dictate one scaling strategy. But when data must be partitioned across machines or regions, the placement of related rows can affect query complexity, latency, and the work needed to keep data consistent. A query that is straightforward on one server may require coordination across partitions when its data is spread out.
That is an architecture challenge, not proof that tables cannot scale. The right test is whether your actual volume, partitioning scheme, geography, and query patterns meet your latency and availability needs. The InfoWorld feature also notes that large in-memory systems are used; neither that approach nor distributed storage is a universal answer.
2. JSON and XML can feel awkward in a relational model
Hierarchical data does not always fit neatly into rows and columns. A database may support JSON or XML, but a native feature does not automatically make nested data effortless to validate, index, query, or evolve. The implementation details matter, including any conversion and indexing costs.
#1 Best Overall
If most operations treat a record as a changing, nested document, a document-oriented approach may fit more naturally. If the data has strong relationships and needs relational constraints or joins, tables may still be useful. Compare the actual operations rather than assuming SQL databases cannot handle structured documents.
3. Mapping rows to application objects adds work
Applications often represent data as objects while relational databases represent it as rows. Translating between those models can add code and create friction when application objects change or when an object’s updates must be turned into database writes.
This is a data-access design issue, not a requirement to hand-convert every value. Libraries and application architectures can reduce the repetitive work, but they do not make every mismatch disappear. Consider how much mapping code your application maintains and whether that cost is more troublesome than the consistency and query trade-offs of another data model.
4. Traditional SQL workflows may not suit real-time workloads
Many familiar database patterns are request-and-response or batch-oriented. Streaming systems and applications with tight latency targets may need continuous processing, event handling, or low-latency access patterns that are not well served by a conventional query workflow alone.
That does not mean every SQL-backed system is non-real-time. The decision depends on the required latency, event volume, processing model, and database implementation. Test the complete path—from event arrival through processing to the result the application serves—rather than judging the language in isolation.
5. JOINs can be hard to write and plan
Joins are a core strength of relational databases: they let applications query related information without storing every copy together. They can also make queries harder to understand as relationships and data volumes grow.
Join performance depends on the query, data, indexes, and chosen plan; joins are not inherently slow. PostgreSQL’s planner documentation explains that the optimizer considers alternative execution plans. It also notes that an exhaustive search can become too costly for queries with many joins, so PostgreSQL’s genetic query optimizer seeks a reasonable plan in those cases. Inspect the plan and workload before concluding that the join itself is the problem.
6. Fixed columns make some schema changes cumbersome
Tables and declared fields can make changes feel rigid when records vary or the application’s data shape evolves frequently. A flexible document structure may make it easier to add or change fields without coordinating a conventional schema change for every variation.
Flexibility shifts work rather than eliminating it. Applications still need deliberate validation, consistency rules, and query conventions. The InfoWorld feature provides no comparative measurements showing that flexible records use less space or are better overall; choose based on how often the structure changes and how important predictable constraints are.
7. An optimizer cannot fix every query or design
Database optimizers can choose among possible execution plans, but they cannot guarantee that every complex query or data design will perform well. Query shape, statistics, indexes, data distribution, and engine behavior all affect the result.
PostgreSQL’s planner documentation describes both plan selection and the limits of searching plans for queries with many joins. Treat optimization as a powerful tool with boundaries: measure the query, examine its plan, and reconsider the data model or access pattern if the design remains a poor fit.
8. Denormalization trades relational discipline for read convenience
Copying data into a structure that is faster or simpler to read can avoid joins and suit a particular access pattern. But denormalization duplicates information that a normalized design would keep in one authoritative place.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallThat can make updates and consistency harder: every relevant copy may need to change together. Denormalization is a conscious trade-off, not a general indictment of tables. It is most defensible when a measured read need justifies the extra work required to maintain consistent copies.
9. Extra SQL features can add complexity when misused
Subqueries, common table expressions, views, and window functions give SQL expressive power. They can also make a query or database harder to reason about when developers use them without understanding their behavior and costs.
The existence of these features does not establish that they generally harm performance. Wayner’s feature uses them as examples in a critique of accumulated complexity, not as a benchmark proving a blanket performance rule. Evaluate the specific query and engine rather than avoiding a feature by reputation.
10. SQL dialects differ, and unsafe query construction creates risk
SQL’s syntax is not identical across database products, so quoting and other dialect details can complicate portability. Separately, constructing queries by concatenating user input can expose an application to SQL injection. Those are two different problems: vendor variation and unsafe handling of input.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →OWASP’s SQL Injection Prevention Cheat Sheet describes the vulnerable pattern as concatenating user-supplied input into dynamic queries and recommends prepared statements or parameterized queries as a primary defense. The practical response is safe query construction—not abandoning SQL categorically.
11. Not every data shape is naturally tabular
Graphs, spatial data, and other specialized structures may be easier to work with in systems built around those operations. Tables can represent many kinds of information, and database extensions may support some non-tabular needs, but the representation and query model still matter.
Start with the operations your application needs. If traversing relationships, performing spatial work, or handling another specialized data shape is central, compare systems designed for that job with the cost of modeling it relationally.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.12. A SQL standard does not make databases interchangeable
SQL has a formal standard, but standards do not guarantee that database products behave identically or support every feature in the same way. The PostgreSQL 17 documentation identifies ISO/IEC 9075 as the “Database Language SQL” standard, names SQL:2023 as its latest update, and says no current DBMS claims full conformance to Core SQL:2023. That is a statement in the PostgreSQL 17 documentation, not a timeless claim about every future release.
Do these 3 things before closing this tab:
1Scan for outdated or missing drivers - takes under a minute2Clear out junk files and repair common Windows errors3Fix the driver behind crashes, sound loss and screen glitchesBest Value
Teams that need portability should check the specific syntax, features, and behavior their application depends on. A shared language is useful; it is not a promise that switching engines will be effortless.
13. There may be a better tool for a particular job
Wayner points to GraphQL for some web applications, alongside NoSQL or document-query approaches and search-oriented systems. These options do different jobs. GraphQL is a query interface, not a database storage model; a search system is not automatically a substitute for a transactional relational database.
Compare alternatives against the workload and data shape, transaction and consistency needs, access patterns, scale and latency targets, operational maturity, security model, portability, and migration costs. A system can use more than one approach when different needs justify the added operational complexity. The InfoWorld feature does not provide product benchmarks or a product ranking, so it cannot establish a universal replacement.
How to decide whether SQL should go
Before replacing a working database, identify the specific problem and verify that it comes from the data model or workload rather than an avoidable query or application design issue.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →- Name the constraint: Is the issue latency, distributed queries, mapping code, schema evolution, specialized data operations, or portability?
- Measure the affected workload: Check the queries and application paths that matter, including their data volume and consistency requirements.
- Compare the actual alternatives: Evaluate their fit for the workload, operational needs, security, and team experience—not just their marketing category.
- Account for migration cost: Include data movement, application changes, dual-running or rollback needs, and the risk of introducing a new consistency model.
- Keep SQL where it fits: Replacing one unsuitable component does not require replacing every relational database in the system.
Wayner’s conclusion captures the distinction between criticism and forecast: “SQL’s limitations may not be enough to drive it into the dustbin of history.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
