New
What is your approach to zero-downtime schema migrations at scale?
Expand-and-contract, online schema change tools, feature flags? Share what has kept large-table migrations boring.
Techarda editors Editorial Answer this
Evaluation guide
How to evaluate database platforms
This guide is for architects, engineering leads and database administrators choosing a database for a new application, consolidating several, or moving off one after a licence or cost change. It assumes you will live with the choice for years, because databases are among the hardest things in a stack to replace.
In short
Use this guide to compare databases on what still matters years after you choose: fit with your data model and access patterns, behaviour under failure, licence terms, operating cost, migration effort and the real cost of leaving. Then shortlist three to five companies on Techarda and test them with your own schema, queries and at least one deliberate failure.
What’s changing in Databases
Before you compare anyone, it helps to know what has shifted in the market, because it changes which questions matter.
Licences have shifted under some open-source databases
Several databases that began as open source have moved to source-available or more restrictive licences, and some communities have forked in response. Check the licence of the exact version and managed service you plan to run.
Vector search is moving into general-purpose databases
Many operational databases now store and search embeddings next to the rest of your data. A dedicated vector database may still suit very large collections or specific features, so test with your own data size and filters.
Distributed SQL is a mainstream option
Databases that spread transactions across nodes and regions are now a common choice for applications that cannot go down. They solve availability problems and introduce new ones in latency, cost and operating skill.
Serverless and branching change how teams work
Managed services that scale to zero and create copy-on-write branches for testing suit development and uneven workloads. Steady, heavy workloads can cost more on them than on provisioned capacity.
What to judge vendors on
Those shifts shape the criteria below. Each one says why it matters and what to ask, so you can take it straight into a vendor call.
| Criterion | Why it matters | What to ask vendors |
|---|---|---|
| 1Fit with your data model and access patterns | Many database problems trace back to a model that does not match how the application reads and writes. Fit matters more than feature lists. | “Here are our main queries and write patterns: which would be fast on your database, which would be slow, and what would you change in our design?” |
| 2Behaviour under failure | Every database looks reliable when nothing is wrong. What matters is what happens to in-flight transactions when a node, zone or region fails. | “What consistency do we get during a node or region failure, how long does failover take in practice, and can we cause that failure ourselves during the trial?” |
| 3Licence and project governance | A licence change can affect what you may run, who may offer it as a service and what support will cost. | “Which licence covers the version we would run, who controls the project, and what commitments do you make about future licence terms?” |
| 4Operating cost at your scale | Storage, I/O, replicas, backups and cross-region traffic often cost more than the compute line on the quote. | “What would our workload cost each month including replicas, backups, I/O and data transfer, and how does that change if our data doubles?” |
| 5Migration and compatibility | Moving data is the easy part. Rewriting queries, stored procedures and application code is where the time goes. | “Which of our queries, procedures and drivers work unchanged, what migration tooling do you provide, and how would we run both systems in parallel?” |
| 6Backup and point-in-time recovery | Recovery is the feature tested least and needed at the worst moment. Restoring a large database can take far longer than people expect. | “How long does a full restore of a database our size take, can we restore to a point in time in another region, and can we test it during the trial?” |
| 7Security and access | Databases hold the data attackers want. Encryption, auditing and identity integration need to work without custom scripts. | “How do you integrate with our identity provider, who holds the encryption keys, and what does the audit log capture and keep?” |
| 8Data portability and exit | Proprietary query languages and features make leaving expensive. You should know the cost of exit before you sign. | “How do we export all of our data and schema in a standard format, how long would that take at our size, and what would it cost?” |
Trade-offs to settle early
No vendor does well on every criterion, and some pull against each other. Decide where you stand on these before the demos start, or the demos will decide for you.
Managed service or self-managed
A managed service takes patching, backups and failover off your team and costs more per unit. Self-managing gives you control of versions and placement, and your team carries the pager.
One general-purpose database or several specialised ones
Fewer databases means fewer skills, backup regimes and security reviews. Specialised engines for search, time series or vectors may perform better, and each one adds operating load.
Strong consistency or lower latency
Keeping every replica in step across regions protects correctness and adds latency to each write. Decide which data needs it and which can tolerate brief lag.
Your cloud provider’s database or an independent vendor
A cloud provider’s own database fits its identity, networking and billing. An independent vendor may run across clouds and on-premises, at the cost of another supplier relationship.
Community edition or commercial agreement
Running a community edition keeps licence costs down. A commercial agreement buys support and sometimes extra features, and ties your costs to that vendor’s pricing decisions.
Red flags
As the answers come back, watch for these. One on its own isn’t a deal breaker, but it deserves a follow-up question in writing.
- Performance figures from benchmarks the vendor designed, with no offer to test your queries.
- Failover claims you are not allowed to test during the trial.
- No reference customer running a workload of your size with a similar availability target.
- No clear answer about the licence of future versions.
- Data export only through the vendor’s own tools or formats.
- Pricing that is precise for compute and vague for I/O, storage growth and data transfer.
Build your shortlist
Start from the application, then use Techarda to narrow the field to three to five companies that fit how it uses data.
- Write down the data model, the main read and write patterns, the availability target and where the data must live.
- Set aside databases built for a different model. A document store and a distributed SQL database are rarely both right for the same job.
- Check the licence and ownership of each option, and read recent stories on Techarda for licence changes, forks and acquisitions.
- Plan a trial with your own schema, a realistic data volume and at least one deliberate failure.
- Use the practitioner questions below to see where teams like yours ran into trouble, then compare side by side.
Companies to consider in Databases
Listed by recent activity on Techarda (what people are reading, following and discussing). The order says nothing about quality, market share or fit for your needs.
Latest Databases stories
Once you have names, recent news is where pricing changes, acquisitions and outages show up first. These are the five newest stories in this category.
What practitioners are asking
News tells you what vendors announced. These open questions show what teams are still trying to work out, with the least-answered first.
New
Postgres everywhere vs purpose-built databases: where do you draw the line?
Vector search, time series, queues, analytics: many teams now start with Postgres extensions. Where has that worked, and where did you need a dedicated engine?
Where evidence is thin
A shortlist is only as good as the evidence behind it, and ours is still growing category by category. Here is what’s missing in Databases right now.
20 of 20 companies have no published reviews
If you’ve run one of these in production, a short review helps the next team decide. Reviews are moderated before they appear.
2 questions with no answers yet
An answer from someone who has made the same decision is often more useful than any guide. Share what worked, what didn’t and what you’d check next time.
Answer a Databases questionFrequently asked questions
What should I ask Databases vendors about fit with your data model and access patterns?
Many database problems trace back to a model that does not match how the application reads and writes. Fit matters more than feature lists. Ask: Here are our main queries and write patterns: which would be fast on your database, which would be slow, and what would you change in our design?
What should I ask Databases vendors about behaviour under failure?
Every database looks reliable when nothing is wrong. What matters is what happens to in-flight transactions when a node, zone or region fails. Ask: What consistency do we get during a node or region failure, how long does failover take in practice, and can we cause that failure ourselves during the trial?
What should I ask Databases vendors about licence and project governance?
A licence change can affect what you may run, who may offer it as a service and what support will cost. Ask: Which licence covers the version we would run, who controls the project, and what commitments do you make about future licence terms?
What should I ask Databases vendors about data portability and exit?
Proprietary query languages and features make leaving expensive. You should know the cost of exit before you sign. Ask: How do we export all of our data and schema in a standard format, how long would that take at our size, and what would it cost?
New to some of the terms in this guide? The glossary explains Distributed SQL database, NoSQL database and Vector database.
This guide is written by Techarda editors to our editorial standards. No vendor paid to appear in it or saw it before publication. See our methodology, the trust dashboard or go back to the Databases hub.