Fifty Years Young: SQL’s Modern Comeback Story

Prototyping stands out as my most enjoyable aspect of software development. I thrive on creating new solutions and bringing concepts to life. Consequently, it’s no surprise that I’m a significant enthusiast of MongoDB and NoSQL databases in general. To be clear, I’ve always recognized SQL’s value, but the seamless experience of integrating MongoDB with JavaScript truly captivated me.

Under the leadership of the innovative PostgreSQL team, SQL has recently made a remarkable resurgence. While it consistently served as the foundation for enterprise data, it now embodies both a reliable, conventional choice and a cutting-edge technology worth observing. How did this transformation occur?

The Rise of SQL: A Modern Revival

The journey began when SQLite, a compact relational database, extended SQL’s reach into web browsers. This browser-based SQL facilitated a novel architecture centered on client-side backend synchronization, with SQL, not JSON, acting as the crucial link. Concurrently, advancements in language tools enhanced the ease of using SQL across various platforms. The inherent reliability of relational architecture steadily won over more users, and PostgreSQL further solidified its position by introducing the flexible jsonb data type.

And that’s precisely how it unfolded: just when its relevance was questioned, SQL found its stride and became exciting once more.

Debunking the ‘Schemaless’ Myth

The primary appeal of NoSQL within JavaScript environments is the ability to manage your database structure, or schema, without deviating from the language’s own paradigm. When adding a new data type during coding, you simply execute a command similar to this:

await db.collection('cats').insertOne({ name: 'Fluffy', mood: 'Judgmental' });

Even if db.cats doesn’t exist yet, the database automatically provisions it. The same principle applies to the data’s “shape” (name and mood). Best of all, you can directly embed the JSON object.

This approach seemingly offers the ultimate frictionless data experience: both the database and the code communicate in JSON. There’s no need to pause and craft a CREATE TABLE statement, execute a migration script, or even consciously consider the data structure. You simply create what you need spontaneously, and the data store adapts.

However, as our initial prototypes evolve into robust production systems, we encounter an inconvenient truth: the schema persists, but it has shifted into our application code. It operates implicitly, often manifesting in patterns like this:

if (cat && cat.mood && typeof cat.mood === 'string')

Or, alternatively:

const mood = cat?.mood ?? 'neutral';

The schema’s enforcement now resides within the application code. This represents a persistent, systemic reality within the “schemaless” paradigm. While similar validation (either in code or via a framework) is performed even with strict schemas, the fundamental consistency of records remains safeguarded by the database itself.

The demands of developing a large-scale system without robust data consistency can induce significant stress. What developers truly seek is strong data integrity combined with minimal operational friction. Fortunately, three convergent trends are now making this achievable with SQL:

• Client-side SQL with robust syncing capabilities
• Enhanced SQL client libraries
• SQL’s adoption of schemaless data types (JSONB)

The first point is innovative and forward-thinking; the second reflects consistent engineering improvements; the third signifies an adaptive evolution.

Let’s delve deeper into each.

SQL in the Frontend Environment

The initial solution involves a fundamental reevaluation of the database’s location. For three decades, databases were formidable entities confined to server rooms, while browsers acted merely as passive terminals requesting data via APIs.

However, thanks to WebAssembly (WASM), we can now execute the *actual* database engine directly within the browser. Innovations like PGlite (PostgreSQL running in WASM) and SQLite (available through standardized browser implementations) have transformed the database into a client-side technology.

This migration to the frontend also spurred the emergence of serverless SQL for analytical and edge computing needs. Tools such as DuckDB empower developers to process millions of rows of analytical data directly on a user’s device or at the network edge, eliminating the need for extensive cloud data warehouses.

While this advancement alone is noteworthy, it becomes truly transformative with the advent of syncing technologies like ElectricSQL. The concept of syncing has existed in the NoSQL sphere with projects like PouchDB, but it is now gaining traction within the SQL ecosystem. Syncing enables the use of the same data store (or a segment thereof) in both the browser and on the server, with the syncing engine seamlessly managing data reconciliation.

Syncing further unlocks the potential for a local-first database architecture. Instead of developing intricate API endpoints (e.g., GET /cats, POST /cats) and managing loading indicators, your frontend code interacts directly with its local database.

When you INSERT a record locally, the operation occurs instantaneously. Subsequently, a background syncing engine (such as ElectricSQL or Replicache) manages the complex task of transmitting that data to the server, effectively removing the need for a dedicated API layer.

Naturally, the transition to a local-first approach demands considerable mental adjustment and carries significant architectural implications. Nevertheless, integrating a relational database directly into the browser positions SQL as a potential new universal data standard.

Enhanced SQL Client Tools

The second contributing factor stems from dedicated engineering effort; specifically, years of consistent refinement applied to database client software.

It turns out that much of SQL’s perception as an outdated, cumbersome technology was largely due to inadequate tooling. Regardless of the programming language in use, writing SQL often involved tedious string concatenation or wrestling with complex, overly abstract Object-Relational Mappers (ORMs).

While ORM solutions like Hibernate/JPA allowed developers to manage data within their preferred language (e.g., Java), they often obscured the underlying mechanisms to a degree that made understanding the actual operations difficult. This abstraction could lead to disorientation when reasoning about data flows and increased the likelihood of errors.

However, a new wave of ORM-lite tools is emerging to bridge this gap. Libraries such as Drizzle (for TypeScript), Exposed (for Kotlin), and jOOQ (for Java) prioritize the developer experience. They effectively translate SQL’s structured nature into the idiomatic expressions of your programming language. For instance, Drizzle enables querying a table to feel akin to filtering a JSON array in TypeScript, all while maintaining full type safety:

const grumpyCats = await db
  .select()
  .from(cats)
  .where(eq(cats.mood, 'Judgmental'));

Such tools eliminate the need for developers to constantly verify if their code aligns with their data. They provide a user experience more akin to MongoDB—where code and data interact seamlessly—without compromising schema integrity.

SQL’s Adoption of Schemaless Data Types

The PostgreSQL development team posed a pivotal question: What if a relational database could effectively handle flexible JSON data? The jsonb type emerged as the answer.

While PostgreSQL pioneered this innovation, other databases have subsequently adopted similar capabilities. This represented a shrewd strategic move, allowing developers to leverage schemaless documents when necessary, yet still within the robust framework of a relational structure.

This development significantly reduced the necessity for polyglot persistence architectures—a trend popular around 2015 that advocated using PostgreSQL for transactional data and MongoDB for catalog-like information.

Instead, JSONB provided strict ACID compliance for vital data such as financial transactions and personally identifiable information (PID), alongside flexible JSON blobs for less structured data like configurations and logs—all within the same database row. This demonstrated that abandoning SQL for flexibility was unnecessary; rather, SQL simply needed to become more adaptable.

JSONB also includes indexing support, ensuring that you can achieve the performance benefits of indexed tables, even when executing hybrid queries that combine standard fields with JSON data.

The substantial architectural advantage of utilizing a single data store is simply too significant to overlook.

Further reading: The evolution and future of JSONB in PostgreSQL.

The Value of Deliberate Structure

Certainly, extensive experience reminds us to avoid overenthusiasm. The industry is not poised to discontinue REST APIs anytime soon. (If that were the case, we’d already be using HTMX.) The current technology stack possesses immense inertia, and for valid reasons: decoupling the client from the database is a time-tested and reliable architectural pattern.

SQL, too, comes with its own set of challenges. You still need to manage connection pools, write migration scripts (even if tooling simplifies the process), and scaling a relational database remains more complex than scaling a document store.

This current trend doesn’t suggest SQL will universally replace other technologies overnight; rather, it signifies a rebalancing of approaches. We are increasingly recognizing that SQL’s inherent “friction”—the requirement to explicitly define types and relationships—is not a flaw but a beneficial characteristic. It compels thoughtful system design before implementation.

SQL and the Lindy Effect Principle

The Lindy Effect posits that a technology’s remaining lifespan is proportional to its current age. SQL has endured mainframes, the personal computer revolution, the rise of the web, mobile computing, and is now navigating the AI era. Its survival isn’t due to stubborn resistance to change but to its remarkable adaptability. So far, SQL has integrated JSON capabilities, scaled down for web browsers, and seamlessly connected with modern programming languages. SQL’s renewed relevance isn’t about eradicating alternatives; it’s about concentrating on core principles, demonstrating that the seemingly conventional path can often be the most fundamentally sound.