There is a particular kind of silence that falls over a technology category shortly before it consolidates. Conference talks get less ambitious. Release notes get shorter. The interesting arguments move from architecture to licensing. And then, over about eighteen months, half the vendors you had on your evaluation shortlist are acquired, relicensed, or quietly no longer accepting new customers.
The specialised database market is somewhere in the middle of that process, and engineering teams that treat database selection as a one-time decision are about to learn why it is not.
The pattern, stated plainly
Categories built around a novel data model follow a recognisable arc. An access pattern that relational systems handle badly creates an opening. Specialist vendors appear, funded generously, competing on capability. Capability converges. Competition moves to price and developer experience. Margins compress. Investors who funded on the assumption of a durable standalone category discover that the market is smaller than modelled, and the endgame arrives in three forms: acquisition by a platform vendor, a licence change designed to convert free users into paying ones, or absorption of the capability into general-purpose systems that were previously “bad at this.”
Graph, vector, time-series and document stores have all travelled some distance along that arc. The specific question for a team choosing today is not which product is best. It is which products will still be independently maintained, under their current licence, in five years — and what the migration cost looks like if the answer is wrong.
Edgewisely’s review of how the graph database category consolidated as licences tightened and a zero-ETL engine arrived is a useful case study, because graph is far enough along the arc that the pattern is visible rather than speculative.
Why licence changes hurt more than acquisitions
Engineers instinctively worry about acquisition. In practice, licence changes are the more disruptive event.
An acquisition usually preserves the product. The acquirer bought customers and technology, and destroying either destroys the asset. Roadmaps slow, prices drift upward, and the product gets bent toward the acquirer’s platform — but the thing you deployed keeps running and keeps receiving patches.
A licence change can invalidate your deployment model overnight. A permissive licence becoming source-available with usage restrictions does not break your running system, but it can make your intended architecture non-compliant, block your ability to offer the capability to your own customers, or force a commercial conversation you had specifically designed around. Teams that adopted a database because it was free to embed have discovered that the embedding was the thing the new licence prohibits.
The defensive move is not to avoid such products. It is to know, before you deploy, which licence you are relying on, which behaviours it permits that a change could remove, and what your position is if it changes. That is a fifteen-minute conversation at adoption time and a six-month project at remediation time.
The convergence problem
The second structural pressure is that general-purpose systems keep absorbing specialised capability. Relational databases acquired JSON handling, then full-text search, then vector indexes, then graph traversal extensions. Each absorption was initially inferior to the specialist and each was, after two or three releases, good enough for most workloads.
“Good enough for most workloads” is the phrase that kills specialist categories, because the operational argument is overwhelming. One system to back up, monitor, patch, secure, staff for and reason about is worth a substantial performance penalty. Teams routinely accept a specialist system that is meaningfully faster on the benchmark and then spend more engineering time on its operational overhead than the performance gain returns.
The honest test is whether your workload is in the tail where the specialist genuinely wins. Sometimes it is — deep multi-hop traversals, very high-cardinality vector search, genuinely large time-series ingest. Frequently it is not, and the specialist was chosen because the access pattern resembled the specialist’s marketing rather than because the general-purpose option had been measured and found wanting.
The zero-ETL argument and what it actually changes
One of the more interesting recent developments is the arrival of engines that query data where it already lives rather than requiring it to be copied into a dedicated store. The pitch is compelling because the copy is where most of the pain sits: pipelines to build, freshness to manage, schema drift to handle, and two sources of truth to reconcile when they disagree.
It is worth being precise about what this eliminates and what it does not. It eliminates the pipeline and the staleness. It does not eliminate the performance characteristics of the underlying store, and querying a transactional database with an analytical access pattern has consequences regardless of what sits in front of it. The right way to evaluate these systems is against the total cost of the pipeline you would otherwise build, not against the specialist’s benchmark numbers.
Practical guidance
For teams making a selection now, four questions are worth answering explicitly and writing down.
What is the migration path if this vendor disappears? Not whether it will, but what happens if it does. A product whose query language is broadly implemented elsewhere carries far less lock-in than one with a proprietary interface, regardless of which is technically better today.
What licence am I depending on, and which specific permission matters to me? Write down the permission, not just the licence name. If a change removes that permission, what breaks?
Has the general-purpose option been measured, or assumed inadequate? Run the benchmark on your data with your access pattern. The answer is surprising often enough to justify the day it costs.
Where does this data need to be in three years? Specialist stores accumulate gravity. Data that arrives in one tends to stay, and every downstream consumer built against it increases the cost of ever moving. Choosing a store is choosing where a portion of your data model lives for a long time.
There is a broader habit worth cultivating here, which is scepticism toward architectural certainty in fast-moving parts of the stack. The retrieval architecture debate is a good parallel: as Edgewisely’s examination of what the research actually says about RAG versus long context shows, confident positions are frequently built on evidence that does not support them. The same applies to data infrastructure. The teams that do well are the ones that treat these decisions as reversible and design accordingly, rather than the ones that pick correctly.
One further note on organisational risk, because it is usually the part that bites. Specialist databases tend to be introduced by one enthusiastic engineer who understands the access pattern deeply and enjoys the technology. That person becomes the de facto owner, and the system’s operational knowledge lives largely in their head. When they leave — and on a five-year horizon they will — the organisation discovers it is running production infrastructure that nobody understands well enough to tune, upgrade or debug under pressure. This is a much more common failure mode than vendor collapse, and it is entirely preventable by insisting that any specialist store has at least two people who can operate it before it carries production traffic. If you cannot find a second volunteer, that is useful information about whether the choice is sustainable.
Quiet categories are not stable categories. They are categories where the interesting decisions have moved from engineering to the balance sheet, and the balance sheet does not send release notes.
You must be logged in to post a comment.