CockroachDB and TiDB: When Distributed SQL Pays Off
Distributed SQL is the category of databases that provide the familiar SQL interface with horizontal scaling and multi region replication. CockroachDB and TiDB are the leaders. They solve the problem of scaling a single database past what Postgres or MySQL can do on a single node. The trade off is operational complexity that most SaaS does not need. The right call depends on whether your scale or geography demands it.
What you actually need to know
- Distributed SQL solves scale and geography problems most SaaS does not have.
- CockroachDB is Postgres flavored. TiDB is MySQL flavored.
- Operational complexity is significantly higher than Postgres or MySQL.
- Most B2B SaaS lives on Postgres with replicas for the life of the company.
- The premature adoption is the most common mistake.
| Database | Compatible with | Best fit |
|---|---|---|
| Postgres single node | Standard SaaS | 99 percent of B2B SaaS |
| Postgres with replicas and partitioning | Growing SaaS | Most large SaaS |
| Aurora Serverless | Variable workloads | AWS deep teams |
| Spanner | Strong consistency, global | GCP deep teams |
| CockroachDB | Postgres flavored | High scale, global, financial |
| TiDB | MySQL flavored | High scale, HTAP |
The core argument
Distributed SQL is one of those technologies that founders consider years before they need it. The marketing is excellent. The case studies are impressive. The promise is appealing. The reality is that most SaaS does not hit the conditions that justify the operational complexity for years, if ever.
The conditions that justify distributed SQL are specific. The single node database has hit its ceiling and partitioning would be the wrong fit. The product requires strong consistency across multiple regions for either latency or compliance reasons. The team has the operational maturity to run the additional complexity.
Most B2B SaaS does not hit these conditions. The Postgres single node serves them well into the tens of millions of dollars in ARR. Read replicas handle the read scale. Partitioning handles specific large tables. The single region serves the customers without strong consistency requirements across regions. The operational simplicity of standard Postgres compounds.
Adopt it too early and you pay the operational tax for years before you need the capability. The cluster has more moving parts, the performance characteristics are different, and the query patterns that worked fine on Postgres suddenly need a second look. The investment is real and rarely pays back until the scale that justified it finally arrives.
Get the timing right and the value shows up on schedule. The scale that broke Postgres now works on the new system. The multi region requirements that Postgres could not meet are met. The operational tax is still real, but at that point it is simply the price of the thing you needed.
The honest decision
| Question | Distributed SQL needed? |
|---|---|
| Are you hitting single node limits on Postgres? | Maybe |
| Have you exhausted read replicas, partitioning, and connection pooling? | Probably yes |
| Do you need strong consistency across regions? | Yes |
| Do you have database operational maturity? | Required either way |
| Are you below ten million ARR? | Almost never |
| Are you above one hundred million ARR? | Worth evaluating |
How much does this cost
| Option | Monthly infrastructure | Operational complexity |
|---|---|---|
| Postgres single node | A few hundred to a few thousand USD | Low |
| Postgres with replicas | One thousand to ten thousand USD | Medium |
| Aurora Serverless | One thousand to ten thousand USD | Lower than self managed |
| CockroachDB Serverless | Free tier to thousands USD | Lower than self managed |
| CockroachDB Dedicated | Two thousand USD minimum, scaling up | Higher |
| TiDB Cloud Serverless | Free tier to thousands USD | Lower than self managed |
| TiDB Cloud Dedicated | Two thousand USD minimum, scaling up | Higher |
Features the database choice must have
- Strong durability guarantees.
- Backup and restore that work.
- Connection pooling appropriate to the scale.
- Performance monitoring.
- A migration path if you need to change later.
- Multi region capability if the product needs it.
- A documented operational runbook.
- A team that can operate it.
Expert opinion
Distributed SQL is a powerful technology that solves a narrow set of problems. Get the timing right and you get years of capability out of it. Jump early and you pay the operational tax without ever using the capability it bought you. The honest question is whether your scale or geography actually requires it. Most teams answer no. Most teams who answer yes were right.
Yashveer Singh, founder of Yashveer Labs
How this played out on a real project
A client SaaS founder asked me to evaluate CockroachDB for their next architecture phase. They were at three million ARR. The Postgres on RDS was running comfortably. The team was small.
We ran the numbers. Postgres would serve them for at least two more years at projected growth. The geographic distribution requirements they thought they had were not actually a requirement, only a preference. The operational tax of CockroachDB at their team size would have been meaningful.
We stayed on Postgres. Added read replicas for the read scale that was coming. Partitioned the two largest tables. The cluster ran comfortably for two more years. By the time the team was ready to evaluate distributed SQL again, their scale and team had grown to the point where the decision was different. They ended up moving the most demanding surface to CockroachDB and kept the rest on Postgres.
For more on the related work, see PostgreSQL vs MySQL vs MongoDB for a new SaaS in 2026 and PostgreSQL vs Supabase vs Neon vs Planetscale.
Common mistakes teams make
- Adopting distributed SQL preemptively.
- Believing the marketing about operational simplicity.
- Skipping Postgres scaling techniques that would have worked.
- Migrating a non distributed application to distributed SQL without rewriting query patterns.
- Choosing CockroachDB without Postgres compatibility verification.
- Choosing TiDB without MySQL compatibility verification.
- Ignoring the cost of the dedicated tier.
- Treating distributed SQL as a drop in replacement.
A 60 day evaluation plan
- Weeks one and two. Document the current database scale and growth trajectory.
- Weeks three and four. Identify whether single node Postgres or Aurora would last another two years.
- Weeks five and six. If distributed SQL is genuinely needed, evaluate CockroachDB and TiDB on a non production workload.
- Weeks seven and eight. Run the migration plan or shelve the project.
For more on the related work, read PostgreSQL vs MySQL vs MongoDB for a new SaaS in 2026 and scaling from one thousand to one hundred thousand users the invisible database bottlenecks. On the broader scaling side, sharding strategies for SaaS when to start and when to stop avoiding it is the natural next read.
FAQ
Frequently asked
- When does a SaaS actually need distributed SQL?
- What is the difference between CockroachDB and TiDB?
- What is the operational cost?
- Can I migrate from Postgres to CockroachDB?
- What is HTAP and does it matter?
- What are the cheaper alternatives?
- What is the most common mistake?
Author
Why you should skip the agency and hire me instead
Agencies markup engineering work by three to five times. Yashveer Singh, founder of Yashveer Labs. I do the work directly. No project manager, no account manager, no overhead. The engineer you talk to is the engineer who writes the code. That changes the math on price, speed, and quality at the same time. If that sounds like the shape of project you have, we should talk.