Loading learning content...
NewSQL databases represent a powerful evolution in database technology—but they're not a universal solution. Understanding when to choose NewSQL versus traditional SQL or NoSQL is as important as understanding the technology itself.
This page synthesizes our NewSQL knowledge into practical decision frameworks. We'll examine ideal use cases where NewSQL excels, scenarios where alternatives are better suited, real-world adoption patterns, and the considerations for migrating to NewSQL.
The goal is to equip you with the judgment to make informed database decisions for your specific requirements.
By the end of this page, you will understand the ideal use cases for NewSQL, when to choose traditional databases instead, how to evaluate NewSQL for your workload, and practical considerations for migration. You'll have a decision framework for database selection in modern distributed systems.
NewSQL shines in specific scenarios where its unique combination of features—ACID transactions, horizontal scalability, and SQL compatibility—provides clear advantages.
Use Case 1: Global Applications with Strong Consistency Requirements
Applications serving users worldwide while requiring transactional correctness are ideal NewSQL candidates:
Use Case 2: Financial and Transactional Systems
Any system where data consistency is legally or operationally mandatory:
Use Case 3: Scaling Beyond Single-Node Limits
When traditional RDBMS hits scaling walls and you can't sacrifice SQL semantics:
| Symptom | Cause | Why NewSQL Helps |
|---|---|---|
| Vertical scaling costs exploding | Largest available server can't keep up | Horizontal scale on commodity hardware |
| Write throughput plateau | Single master can't handle writes | Multiple range leaders, distributed writes |
| Read replicas lagging | Replication can't keep up | Consistent reads from any replica |
| Failover causing outages | Promotion takes minutes | Automatic failover via Raft (<10s) |
| Sharding complexity unsustainable | Manual shard management | Automatic range splitting and rebalancing |
Use Case 4: High Availability Requirements
When downtime has severe business impact:
NewSQL is most valuable when you need ALL THREE: (1) SQL/ACID semantics, (2) horizontal scalability beyond single-node, and (3) high availability/geographic distribution. If you only need one or two, simpler solutions often suffice.
Examining how organizations have deployed NewSQL provides practical insight into its application.
Google Spanner Deployments
Cloud Spanner Customer Examples
| Company | Use Case | Why Spanner |
|---|---|---|
| Snap (Snapchat) | Ad targeting and analytics | Global scale, low latency, strong consistency |
| Electronic Arts | Player data, leaderboards | Global gaming, consistent state |
| Major banks (undisclosed) | Core banking | ACID compliance, geo-redundancy |
| Home Depot | Inventory management | Real-time inventory across stores |
CockroachDB Production Deployments
| Company | Use Case | Why CockroachDB |
|---|---|---|
| Netflix | Control plane data | Multi-region, PostgreSQL compatibility |
| SpaceX | Starlink user management | Global users, transactional requirements |
| Bose | IoT device management | Scale, reliability, PostgreSQL migration |
| Comcast | Customer data platform | Scale, consistency, compliance |
| DoorDash | Order management | High availability, strong consistency |
Notice the commonalities: these are mission-critical systems where consistency matters, scale is required, and the cost of downtime or data inconsistency is high. NewSQL adoption is driven by requirements, not technology curiosity.
NewSQL is not always the right choice. Understanding anti-patterns prevents costly mistakes.
Anti-Pattern 1: Small-Scale Applications
If your application fits comfortably on a single PostgreSQL or MySQL instance (which handles millions of rows and thousands of QPS), NewSQL adds complexity without benefit. The operational overhead, learning curve, and potentially higher costs aren't justified by workloads that don't need horizontal scaling.
Anti-Pattern 2: Analytics and OLAP Workloads
NewSQL databases are optimized for OLTP (transactional) workloads, not analytics:
Anti-Pattern 3: When Eventual Consistency Suffices
If your application can tolerate eventual consistency, NoSQL databases often provide:
Examples where eventual consistency works:
Anti-Pattern 4: Schemaless or Highly Polymorphic Data
NewSQL requires schemas. If your data is:
Then document databases (MongoDB), key-value stores (Redis, DynamoDB), or wide-column stores (Cassandra) may be more appropriate.
Anti-Pattern 5: Extreme Latency Requirements
For sub-millisecond latency requirements:
| Requirement | Best Fit | Why |
|---|---|---|
| SQL + Scale + Consistency | NewSQL | That's exactly what it's for |
| SQL + Single-node sufficient | PostgreSQL/MySQL | Simpler, battle-tested |
| Scale + Flexible schema | Document DB (MongoDB) | Schema flexibility, horizontal scale |
| Extreme scale + Eventual OK | Cassandra | Massive write throughput |
| Key-value + Sub-ms latency | Redis | In-memory, optimized path |
| Graph relationships | Neo4j | Native graph traversal |
| Time-series data | InfluxDB/TimescaleDB | Optimized for time-series patterns |
| Analytics/OLAP | BigQuery/Snowflake | Column-oriented, massive scale |
Use this structured framework to evaluate whether NewSQL fits your requirements.
Step 1: Identify Your Core Requirements
Answer these questions honestly:
Step 2: Apply the Decision Matrix
1234567891011121314151617181920212223242526272829
// NewSQL Decision Matrix function chooseDatabase(requirements): if requirements.needsSQL == false: return evaluateNoSQL(requirements) if requirements.consistencyRequired == false: return evaluateNoSQL(requirements) if requirements.scaleExceedsSingleNode == false: // PostgreSQL or MySQL is probably sufficient return "Traditional RDBMS (PostgreSQL, MySQL)" // At this point: SQL + Consistency + Scale needed if requirements.multiRegion: if requirements.gcpOnly: return "Cloud Spanner" else: return "CockroachDB or YugabyteDB" if requirements.mysqlCompatibility: return "TiDB" if requirements.postgresCompatibility: return "CockroachDB or YugabyteDB" // Default NewSQL recommendation return "CockroachDB (most flexible)"Step 3: Validate with Benchmarks
Before committing:
If you're unsure, start with PostgreSQL. Design your schema and application with future migration in mind (avoid PostgreSQL-specific features that NewSQL doesn't support). When you actually hit scaling limits, migrate. Many successful companies ran on single-node databases for years before needing distributed solutions.
Migrating to NewSQL requires careful planning. Here are key considerations.
Schema Compatibility
Evaluate what changes are needed:
| PostgreSQL Feature | CockroachDB Support | Migration Action |
|---|---|---|
| SERIAL/IDENTITY | Supported (with caveats) | Consider UUIDs for distributed safety |
| PL/pgSQL functions | Limited | Rewrite as application logic or SQL UDFs |
| Triggers | Partial | Move to application layer or changefeeds |
| Foreign keys | Fully supported | No change needed |
| JSONB | Fully supported | No change needed |
| Full-text search | Basic support | May need external search service |
| PostGIS | Not supported | Use native geo types or external service |
| Extensions | Not supported | Find alternatives or rewrite |
Designing for Distribution
Some schema patterns that work on single-node PostgreSQL don't distribute well:
Problem: Sequential Primary Keys
1234567891011121314151617181920212223242526272829303132
-- BAD: Sequential IDs create hotspots-- All inserts go to the same range leaderCREATE TABLE events ( id SERIAL PRIMARY KEY, -- Sequential = all writes to same range event_type TEXT, payload JSONB); -- GOOD: UUIDs distribute writes across rangesCREATE TABLE events ( id UUID PRIMARY KEY DEFAULT gen_random_uuid(), event_type TEXT, payload JSONB); -- GOOD: Natural compound key with good distributionCREATE TABLE events ( user_id UUID, event_time TIMESTAMP, event_type TEXT, payload JSONB, PRIMARY KEY (user_id, event_time) -- Distributes by user); -- GOOD: Shard ID + sequence for ordered-within-shardCREATE TABLE events ( shard_id INT, -- Hash of user_id % 1024 event_id SERIAL, event_type TEXT, payload JSONB, PRIMARY KEY (shard_id, event_id));Application Changes
Applications may need modifications:
Consider dual-write migration: write to both old and new database, verify consistency, gradually shift reads, then cut over writes. Tools like CockroachDB's MOLT (Migrate Off Legacy Technology) can help with initial data migration.
NewSQL has different cost profiles than traditional databases. Understand these before committing.
Cloud Spanner Costs
Cloud Spanner is priced per node-hour:
| Configuration | Compute (3 nodes) | Storage (1TB) | Monthly Total |
|---|---|---|---|
| Regional (single region) | ~$2,000 | ~$300 | ~$2,300 |
| Multi-region (nam-eur-asia1) | ~$9,000 | ~$500 | ~$9,500 |
Spanner's minimum cost (1 node, regional) starts around $650/month. This makes it unsuitable for small projects but reasonable for production workloads.
CockroachDB Costs
CockroachDB offers more flexible options:
| Option | Starting Cost | Best For |
|---|---|---|
| Self-hosted (Core) | $0 + infra | Full control, existing infra |
| Serverless | $0 (free tier) | Development, small workloads |
| Dedicated (3-node) | ~$600/month | Production with SLA |
| Enterprise (self-hosted) | Contact sales | Large scale, on-prem |
Total Cost of Ownership Analysis
When comparing costs, consider:
Start with the minimum viable cluster (3 nodes). NewSQL's ability to add nodes seamlessly means you don't need to over-provision upfront. Monitor utilization and scale when you reach 60-70% capacity.
NewSQL is part of a broader evolution in database technology. Understanding these trends informs strategic choices.
Current Market Trends
Technology Evolution
NewSQL systems continue to improve:
| Area | Current State | Future Direction |
|---|---|---|
| Latency | Consensus overhead adds ms | Optimistic protocols, speculation |
| Compatibility | 90%+ PostgreSQL/MySQL | Full compatibility goals |
| Cost efficiency | Higher than single-node | Better resource utilization, serverless |
| Operational simplicity | Good but not trivial | Self-tuning, AI-assisted operations |
| Analytics support | Limited OLAP performance | Vectorized execution, columnar storage |
| Edge deployment | Data-center focused | Edge-native distributed databases |
Competitive Landscape
Traditional database vendors are responding:
The database market is converging: relational databases adding distribution, distributed databases adding SQL/ACID.
The trend suggests that distributed SQL will become the default for new applications at scale. Investing in NewSQL knowledge positions you well for this future while skills translate to improved understanding of all database systems.
We've completed our comprehensive exploration of NewSQL databases. Let's consolidate the key decision criteria and conclude the module.
Module 1 Complete: NewSQL Databases
Over these five pages, we've explored:
You now have a principled understanding of NewSQL that enables informed database selection for your projects.
Congratulations on completing Module 1: NewSQL Databases! You've mastered the concepts, architecture, and practical considerations for this transformative database category. The next modules in Chapter 40 will explore other modern database topics: In-Memory Databases, Time-Series Databases, Cloud Databases, Multi-Model Databases, and Database Trends.