For more than 50 years, people have been predicting the death of SQL. As Prof. Andy Pavlo says, "Somebody invents a SQL replacement every decade. It then fails and/or SQL absorbs the key ideas into the standard. Every NoSQL DBMS (except Redis) now supports SQL."

Today, the latest challenge comes from AI. At a recent keynote, Databricks CEO Ali Ghodsi declared that "AGI is here today." The implication is that natural language interfaces and agents may eventually replace SQL. Yet the reality is more nuanced.

The recently released BEAVER enterprise Text-to-SQL benchmark shows that even the most advanced models still struggle with real-world enterprise SQL tasks. As of 27 February 2026, the latest benchmark results are: Claude 4.5 Sonnet: 11.4% and GPT-5.2: 10.8%.

These models have improved a lot over the past few months. But when faced with large enterprise schemas, complex joins, domain-specific knowledge, nested queries, and analytical workloads, they are still far from reliably replacing SQL expertise.

The lesson is that SQL keeps proving remarkably resilient. Just as it survived many "SQL killers," it is likely to evolve alongside AI rather than be replaced by it. After more than half a century, SQL remains the lingua franca of data. RIP SQL? Not anytime soon.

For the last five years or so, I've had to deal with countless applications where the front-end and middle tiers are built around Kubernetes (k8s).

I'm sure there are companies out there that use it extremely well, but in my experience, most seem to have no idea what they're doing with it. The result is an endless stream of headaches: runaway database connection counts, configuration problems, networking issues, and countless other problems that end up ruining my evenings and weekends.

Take today, for example. I'm supposed to be off. Instead, I'm sitting on a troubleshooting call with 40 other people. I'm there representing the database team because their pods keep failing, and naturally, the database is getting blamed.

Meanwhile, the database is sitting at 99% idle, and the connections from their application have been sitting idle in transaction for minutes at a time.

The frustrating part is that they don't seem to understand the tools they're using. I'll freely admit that I'm no Kubernetes expert either, but I'm also not the one who designed and deployed an application around it.

I'm sure Kubernetes is fantastic when implemented and managed properly. But from where I sit, it often seems to introduce layers of complexity that nobody fully understands, making troubleshooting an absolute nightmare.

Anyone else developed a particular hatred of k8s, or am I just consistently encountering terrible implementations?

had an interview today where the interviewer asked me to explain different types of databases. I covered the standard SQL and NoSQL categories, but then they pushed for more specialized use cases and claimed that Redis is a database. I was completely flabbergasted. By strict definition, it might fit the category, but I’ve always viewed it primarily as an in-memory cache/store. In my mind, it doesn't meet the core expectations of a primary database—mainly reliable, long-term persistent storage out of the box (even though I know persistence modules exist). What are your thoughts? Do you consider Redis a "real" database in system design, or strictly an in-memory cache with extra steps?

Edit: So we have people between yes vs no vs depends on scenario But just out of curiosity people who are mentioning it is a database, will you store, your user data in it ? I know, i might be sounding dumb but as per my current opinion(I'll try to go deeper into it may be it might change after sometime not sure) if no one is using it as a database. Can we even call it a database? and it is not even optimised for that scenario.

From the first DBMS to the relational model, SQL, transaction processing, and enterprise databases like Oracle and PostgreSQL, these pioneers laid the foundation for database systems.

There are also many other database researchers and engineers who have contributed a lot to database systems, including Patricia Selinger, Raymond Boyce, and many others.

databases used by multi billion dollar companies?

After struggling to land a job in 2024 (when the market was pretty rough), I decided to take a different route and build something real.

I’ve spent the past year working on a MongoDB GUI from scratch, putting in around 90 hours a week. My goal was simple: either build something genuinely useful, or build something that could boost my experience more than anything else

I also intentionally limited my use of AI while building the core features/structure. I wanted to really understand the problems and push myself as far as possible as an engineer.

The stack is Electron with Angular and Spring Boot. Despite that, I focused heavily on performance:

• Loads 50k documents in the UI smoothly (1 second for both the tree and table view each document was around 12kb each)

• Can load ~500MB (50 documents 10mb each) in about 5 seconds (tested locally to remove network latency)

Some features:

• A visual query builder (drag and drop from the elements in the tree/table view) - can handle ANY queries visually

• An aggregation pipeline builder that requires you to know 0 JSON syntax (making it bidirectional - a JSON mode and a form based mode)

• A GridFS viewer that allows you to see all types of files, images, PDFs, and even stream MP4s from MongoDB (that was pretty tricky)

• A Table View (yes, it might seem like nothing, but I'm mentioning this because tables are really hard...) I basically had to build my own AG Grid from scratch, and that took 9 months of optimizations on and off...

• Being able to split panels by dragging and dropping tabs like a regular IDE

• A Schema viewer that can export interactive HTML diagrams (coming in the next ver)

• Imports/Exports that can edit/mask fields when exporting to csv/json/collections

And a bunch more ...

You can check it out at visualeaf.com, and I also made a playground for ppl to try out on there

If you want to see a full overview I made 3 weeks ago, here's the link!

https://www.youtube.com/watch?v=WNzvDlbpGTk

Ohkk this has been in my head for days lol like when ppl say “the database has millions of rows” or “a few GB of data” then how does it still find one row so fast when we do smtg like

Example : "SELECT * FROM users WHERE id = 123;"

Imean like is the DB really scanning all rows super fast or does it jump straight to the right place somehow? How do indexes actually work in simple terms? Are they like a sorted list, a tree, a hash table or smtg else? On disk, is the data just a big file with rows one after another or is it split into pages/blocks and the DB jumps btwn them? And what changes when there are too many indexes and ppl say “writes get slow”??

https://dveeden.github.io/mysql-history-graph/

There are tons of relational database services out there, but only Oracle has a history of suing and overcharging its customers.

I understand why a company would stick with Oracle if they’re already using it, but what I don’t get is why anyone would adopt it now. How does Oracle keep getting new customers with such a hostile reputation?

My assumption is that new customers follow the old saying, “Nobody ever got fired for buying IBM,” only now it’s “Oracle.”

That is to say, they go with a reputable firm, so no one blames them if the system fails. After all, they can claim "Oracle is the best and oldest. If they failed, this was unavoidable and not due to my own technical incompetence."

It may also be that a company adopts Oracle because their CTO used it in their previous work and is too unwilling to learn a new stack.

I'm truly wondering, though, if there are legitimate technical advantages it offers that makes it better than other RDBMS.

So i am on a journey to learn new languages and tools and i am building a small side project with everything that i learn. I want to try build a system with mongodb and i want to know would this example be better for a traditional relational db or mongodb.

Its just a simple system where i have games on a site, and users can search and filter through the games. As well as track whether they have completed the game or not.

we use MSSQL 2019

and yea so hypothetically my manager dropped the database which in turn deleted all the stored procedures I needed for an application development, and hypothetically the development database is never backed up, cause hypothetically my manager is brain dead, is there any way I can restore all the SPs?

EDIT: The database was dropped on a weekend while I'm sipping morning coffee, and yes its only the DevDB not the production so as the only developer in the company I'm the only one affected.

EDIT2:I asked the Manager about the script used for the drop and its detached, and it'll delete the MDF and logs, copy the upper environment's MDF and logs and rename it as the devs, the recycle bin doesnt have the mdf and logs, full recovery is on simple mode

Last Edit: I fixed the problem?? I recreated my sprocs, added them to git using the database project on visual studio, and added a backup procedure on my development environment. good thing I have my sprocs stored at the little corner of my head.

for those saying I should've created the back up as soon as possible, time constraints wouldnt let me. the President which dont know a thing about the technicalities of such things want something to be presented within a month of my employment. so all other procedures are thrown at the back lines of my job list, and the supposed problem...erm Manager didnt give me an access to the server and only gave it to me when the database was dropped and I only have some read and write access on windows auth.

Thanks to ya'all

I had a conversation on LinkedIn with a startup founder, and it opened my eyes. Why all the dependencies? The world can be so simple without databases and their complicated architecture. 𝐉𝐮𝐬𝐭 𝐮𝐬𝐞 𝐟𝐢𝐥𝐞𝐬! Alleluja! 🙏

https://fooba.link/no-databases

Yes, just dump data into JSON format and save it to disk. Load it on demand and iterate over the rows. To make it more performant, cache the data in RAM. And yes, you need a unique key lookup table. And maybe a hash table for indexes. And then maybe a proper storage layer. And a query planner would be good. And ... And ...
Wait a minute! Are we developing a database here? 🤨 AAAAAhhhh....!!! 😭

Short background, I currently am working on a small project at work that involves a Postgres Database, .NET Backend as well as a bunch of files users can run CRUD operations on. Its a pretty low frequency app that never is used by more than 3 people at the same time and the files we are talking are in the 1 - 10 mb range.

One thing most developers (who mostly write Backend code in C#, python, java, ... and not SQL) seem to believe that it is a cardinal sin to store the contents of the files directly inside the database, yet seem happy to store all the metadata like filename, last access, owners, ... in there. In my opinion this causes a number of issues - full backups of the system become more complicated, there is no easy mechanism to guarantee atomicity on operations like there is on a db with transactions (for example deleting a file might delete the record form the table, but not the actual file on the filesystem because some other process has a lock on it), having files both on the disk and the db limits how much you can normalize (for example the filename and location need to be stored redundantly ... also in theory a file could exist in the db but not on the filesystem anymore or the other way around).

I get that you might cause some overhead from having to go through another layer (the DB) to stream the content of your file, but I feel like unless your application has a huge number of concurrent users´streaming giant files, any reasonable modern server should handle this with ease.

Curious to hear the opinion of other people from the DB side or what I'm overlooking.

Object storage is becoming the primary storage layer for modern database systems. Not as backup, archival storage, or a cold tier, but as the primary durable storage layer. As a result, more and more data systems are being designed around the assumption that durable data lives in object storage, while compute becomes ephemeral and elastic.

Examples span almost every category of the data stack: Snowflake and Databricks, Neon and TiDB, RisingWave streaming database, turbopuffer, LanceDB, Milvus, Chroma, and SlateDB.

The workloads, query engines, and consistency models are different, yet they all converge on the same architectural principle: decoupling compute and storage, with object storage serving as the durable storage layer.

The benefits of using object storage are obvious: low storage cost, unlimited capacity, high durability, elastic compute, and simplified operations. But object storage is not a free lunch. Its primary challenges are no longer disk management or capacity planning, as in traditional storage systems. Instead, they include request amplification, metadata scalability, read/write operation costs, cache management, tail latency, and consistency semantics.

As all data systems have their own trade-offs and related engineering challenges, so do object-storage-native database systems. Still, this is becoming a fundamental storage architecture pattern used across databases with different workloads.

With the recent news about mass layoffs of the MySQL staff at Oracle, no git commits in real time on GitHub since long time ago and with the new releases clear signs that Oracle isn't adding new features seems a lot of architects and DBAs are now scrambling for migration plans (if still on MySQL, many moved to MariaDB years ago of course).

For those running their own custom app with full freedom to rearchitect the stack, or using the database via an ORM that allows them to easily switch the database, many seem to be planning to migrate to PostgreSQL, which is mature and has a large and real open source community and wide ecosystem support.

What would the reasons be to not migrate from MySQL to PostgreSQL? Is autovacuuming in PostgreSQL still slow and logical replication tricky? Does the famous Uber blog post about PostgreSQL performance isues still hold? What is the most popular multi-master replication solution in PostgreSQL (similar to Galera)?

it feels like every time i start a project, people want to talk about distributed systems, global scaling, and no-sql flexibility before we even have enough rows to fill an excel sheet.

it is a total trap. we spend weeks setting up these complex, "future-proof" clusters that are a nightmare to query and even harder to back up. we are basically building a rocket ship to go to the grocery store. meanwhile, a simple, "boring" postgres or mysql setup on a single server could handle our entire workload with 90% less stress and a much smaller bill.