Choosing the Right LLM: What 50 Years of Databases Teach Us

My love for software development started with Foxbase database and then later with Foxpro. My first real world application was built for my high school using Foxpro for DOS. I have spent three decades in the computing industry since then, and I have never seen a technology cycle rhyme this precisely. The database industry ran a fifty-year experiment on exactly the question the AI industry is now asking: does the technology itself remain the moat, or does value migrate somewhere else?

We know how that experiment ended. And the LLM market is speedrunning the same script.

Wave one: when the query was the miracle

When relational databases arrived, the ability to query large volumes of data efficiently was genuinely revolutionary. Edgar Codd’s relational model turned data retrieval from a bespoke engineering project into a declarative question: describe what you want, and the engine figures out how. Businesses that could interrogate their own data in seconds instead of weeks had a real, structural advantage.

The first wave of database companies built empires on technical moats. Oracle, IBM DB2, Sybase, Informix: they competed on raw engineering. Fastest query performance. Biggest tables. Best concurrency control. Vertical scaling on ever-larger machines. TPC benchmarks were marketing weapons, because the technology itself was the product.

Sound familiar? Swap “TPC benchmark” for “MMLU score” and you have described the frontier model race of the last three years. Leaderboards as battlegrounds. Capability as moat. The assumption that the best engine wins the market.

Wave two: open source changes the form factor, not the physics

Then MySQL and PostgreSQL showed up, and something subtle happened. At a high level, these open source databases did the same thing Oracle did: tables, SQL, transactions, indexes. The relational physics were identical. What changed was the form factor.

Nobody needed Oracle to run a simple web application. The licensing cost, the DBA overhead, the hardware requirements: all of it massively overserved the actual job. MySQL was good enough for the read-heavy workloads of the early web, and it was free. The LAMP stack became the default substrate of the internet not because MySQL out-engineered Oracle, but because it fit the use case.

This is the first great lesson of database history. Open source did not beat proprietary databases on benchmarks. It beat them on form factor, cost, and accessibility.

The open-weight model ecosystem is running this exact play. Llama, Mistral, Qwen, DeepSeek, Gemma: at a high level they do the same thing the frontier labs’ models do. They predict tokens, follow instructions, write code, summarize documents. The physics are shared. What differs is the form factor: models you can fine-tune, models you can run on-premises for compliance, models small enough for a phone. Nobody needs a frontier model to classify support tickets, just as nobody needed Oracle to run a blog.

Wave three: trading sacred guarantees for scale

The third wave was the Big Data era, and it introduced a move that would have been heresy a decade earlier: deliberately trading away transactional accuracy.

NoSQL databases like MongoDB, Cassandra, CouchDB, and RethinkDB abandoned the ACID guarantees that defined the relational era and embraced eventual consistency. Why? Because the workload changed. Web-scale applications needed to scale horizontally across clusters of commodity machines, not vertically on one enormous Oracle box. The CAP theorem forced a choice, and a new generation of architects chose availability and partition tolerance over strict consistency, because for their applications that was the right trade.

The lesson: correctness is workload-relative. Eventual consistency was not a compromise of principle. It was an engineering trade made deliberately, for specific applications, by architects who understood what their systems actually required.

LLMs embody this same trade at their core. A probabilistic model that occasionally hallucinates is the eventual consistency of the AI era: unacceptable for some workloads, perfectly rational for others, and transformative when matched correctly. The architects who reflexively demand deterministic guarantees for every task are making the same mistake as the DBAs who insisted every web app needed two-phase commit.

Wave four: specialization everywhere

Then the Cambrian explosion: time series databases (InfluxDB, TimescaleDB) for telemetry. Graph databases for relationship traversal. Multi-modal databases. NewSQL systems like CockroachDB and MemSQL that reunited horizontal scale with transactional guarantees. And more recently, vector databases purpose-built for similarity search, which not coincidentally exist to serve LLM applications. Today’s DB-Engines ranking tracks hundreds of engines across more than a dozen categories. Each specialized engine won not by being generally better, but by being specifically better. A time series database will destroy PostgreSQL on high-cardinality telemetry ingestion, and it would be a terrible place to store your billing records.

And alongside the flourishing, a funeral: Hadoop. A decade ago Hadoop was the inevitable future of data infrastructure, with its own conference circuit, vendor wars, and billion-dollar valuations. Then the world moved to cloud object storage and elastic compute, and Hadoop’s core premise, bringing compute to data on commodity clusters you operate yourself, simply stopped being the best answer. Cloudera and Hortonworks merged in retreat. The technology didn’t fail. The premise expired.

Hold onto that, because some of today’s celebrated AI infrastructure carries the same expiration risk. Entire toolchains built around scarce GPU orchestration, prompt-era workarounds, and model limitations that will not exist in twenty-four months are the Hadoop of this cycle. Betting on infrastructure that exists only to compensate for a temporary constraint is how you end up sponsoring the last Hadoop Summit.

The real winners sold the service, not the engine

Now look at who actually won the data infrastructure war: Snowflake and Databricks. Neither won by owning the fastest engine, and this is the part the AI industry keeps missing. Query engines were largely commoditized by the time they rose. Snowflake and Databricks won by solving the problems around the engine: the data lake mess, elastic parallel query processing, separation of storage and compute, governance, sharing, and the operational burden of running data infrastructure at all. They sold an outcome. The engine was an implementation detail.

Database technology is commoditized. PostgreSQL is arguably the finest relational database ever built, it is free, and its excellence generates almost no enterprise value for a “PostgreSQL company.” The value is in the managed service, the reliability, the integration, the ecosystem. Technology became table stakes. Service became the moat.

The uncanny parallel

Map the two eras side by side and the correspondence is uncanny.

Today we have a plethora of LLMs at every scale. Some open, some closed. Some run locally on a mobile device, some require a humongous datacenter and a nine-figure training run. Some are generalists, some are tuned for code, for medicine, for legal reasoning, for function calling. The Stanford AI Index documents the pattern year after year: the capability frontier keeps advancing, and the capability floor keeps rising faster, which is exactly the compression dynamic that commoditized databases.

Just as a data architect chooses the appropriate database technology for a specific business application, we now have to choose the right model for the job. Which brings us to the title of this piece. “Just use Claude” is the new “just use Oracle.” The frontier labs, Anthropic, OpenAI, Google DeepMind, Meta, Mistral, build genuinely remarkable engines, and that is precisely the trap. When the engine is that good, reaching for it by default for every workload feels safe, the way buying Oracle once felt safe. But defaulting to a frontier model for everything is not only an expensive decision, it is frequently not even the best choice technologically. A small model fine-tuned on your domain, running at 50 milliseconds of latency on hardware you control, will beat a frontier model on plenty of production workloads: on cost, on latency, and sometimes on accuracy.

The technology is never going to be the moat

Here is the uncomfortable conclusion for anyone whose strategy is “we have the best model”: the real winners in the LLM space will be the providers who offer services built around the models. The technology itself is never going to be the moat, for the same reasons it wasn’t in databases.

First, capabilities converge. Every architectural breakthrough diffuses through the industry in months. The relational model wasn’t a durable moat; transformers aren’t either. Second, good enough arrives fast. Most enterprise workloads don’t need the frontier, just as most web apps never needed Oracle. Third, value pools around the problem, not the engine. Snowflake didn’t win on query speed, and the AI winners won’t win on benchmark scores. They will win on workflow, domain data, integration, trust, governance, and measurable outcomes.

This is not a pessimistic take on model labs. Oracle is still a colossal business. But the shape of the market changed: the engine became one component in a value stack owned by whoever sits closest to the customer’s actual problem.

There is a corollary here for the build-versus-buy decision, and it is where I see enterprises go wrong most often. Companies that go down the build path almost always forget this reality. They wire their internal tooling to a single frontier API and inherit its cost curve, its latency, and its rate limits for workloads that never needed frontier reasoning in the first place. Building your own support AI on one frontier model is choosing Oracle for every application, except this time you also have to operate the deployment yourself. Multi-model orchestration is not a feature you bolt on later. It is an architecture you either start with or expensively retrofit.

Early innings, and a great time to be an architect

We are in the early innings. If the database analogy holds, and I believe it holds almost move for move, expect the coming years to bring an explosion of specialized models in different form factors: on-device models, vertical domain models, models specialized for agentic tool use, for long-horizon planning, for real-time voice. Expect a Hadoop-style extinction event for infrastructure built on temporary constraints. Expect the market’s center of gravity to keep shifting from “who has the smartest model” to “who delivers the most reliable outcome.”

Most of all, expect the role of the application architect to matter more, not less. The database era’s ending wasn’t boring; it was liberating. Commoditization of the engine is what made the modern data stack possible. The same liberation is coming for AI builders: a rich, interchangeable palette of models, chosen per workload, composed into systems.

It is an interesting world for application architects, and it is about to get a lot more interesting.