PostgreSQL vs YugabyteDB vs CockroachDB (2026): Which Wins for Distributed SQL

Last updated October 2026.

Most teams that search for distributed SQL are not shopping for a new database. They are escaping a specific pain: a single PostgreSQL primary that has run out of write headroom, a failover runbook nobody trusts at 3 a.m., or a requirement that data for one country stay in that country. The trouble is that “distributed SQL” is sold as one category when the three leading answers behave very differently under load, under partition, and on the invoice.

In 2026 the choice has also shifted for non-technical reasons. CockroachDB moved to a proprietary software license, YugabyteDB kept its Apache 2.0 core but still trails the PostgreSQL release train, PostgreSQL itself keeps getting faster on one node, and cloud-native entrants such as Amazon Aurora DSQL and Google Spanner changed what “managed” means.

This guide compares plain PostgreSQL, YugabyteDB, and CockroachDB at the mechanism level: consensus, transactions, isolation, geo-placement, latency, compatibility, licensing, and operations. It also covers a use case rarely discussed in these comparisons, IoT and industrial time-series workloads. You will leave with a decision matrix and a clear rule for when the boring answer, one well-tuned PostgreSQL, still wins.

What this covers: how each system replicates and commits, isolation levels, geo-partitioning, licensing and version status as of October 2026, Aurora DSQL and Spanner context, IoT fit, failure modes, and a decision framework.

Context and Background

Relational databases were built around one machine owning the truth. PostgreSQL scales that model very far: vertical scaling, read replicas via streaming replication, and declarative partitioning take most workloads well past the point where teams assume they need something exotic. High availability comes from tooling around it, commonly Patroni or a managed service, with an asynchronous or synchronous standby promoted on failure.

The distributed SQL idea, popularized by Google’s Spanner paper, is different: split every table into small shards, replicate each shard with a consensus protocol, and run transactions across shards with a commit protocol that survives node loss. The database stays a SQL database, but no single node is special. Two open designs followed Spanner’s lead. CockroachDB reimplemented the storage and SQL layers from scratch. YugabyteDB took a different route: it reuses PostgreSQL’s actual query layer code and replaces storage beneath it with a distributed document store.

That architectural difference explains most of what follows. Compatibility, upgrade cadence, feature gaps, and even failure behavior flow from whether a system is PostgreSQL, speaks PostgreSQL, or embeds PostgreSQL.

Where do the three stand today? PostgreSQL 18 shipped in September 2025, and the PostgreSQL 19 beta 4 announcement shows 19 in beta with general availability expected in October 2026; the community reverted several features, including SQL/PGQ and temporal updates, to protect release quality. Our own PostgreSQL 19 upgrade guide covers what survived. YugabyteDB’s release page lists v2025.2 as an LTS series and v2026.1 as a standard-term (STS) series, with the next LTS, v2026.2, estimated for the end of 2026. CockroachDB’s release notes list v26.3 (an Innovation release, generally available August 19, 2026), v26.2 (April 27, 2026), and v25.4 (November 3, 2025).

A caveat on versions: both vendors revise support windows. Treat the numbers in this article as accurate on October 6, 2026 and re-check the vendor pages before you commit a roadmap.

Why this comparison is harder than it looks

Benchmark blog posts dominate search results for this topic, and most are not comparable. They differ in instance types, replication factor, isolation level, client retry policy, and whether the cluster spans zones or continents. A three-node cluster in one availability zone says nothing about a three-region deployment where the speed of light sets your commit latency. This article therefore avoids headline throughput numbers and reasons from mechanisms, with worked latency arithmetic clearly labelled as illustrative.

For a broader view of how time-series stores fit alongside these engines, see our comparison of PostgreSQL 18, TimescaleDB, and ClickHouse for IoT.

Reference Architecture: How Distributed SQL Commits a Write

Direct answer: A distributed SQL database splits tables into shards, called tablets in YugabyteDB and ranges in CockroachDB. Each shard has a Raft group with one leader and followers. A write commits when a majority of replicas persist it, and a multi-shard transaction adds a commit record so all shards agree atomically. PostgreSQL instead ships a single write-ahead log to standbys.

Figure 1: A distributed SQL write. Any node accepts the query, a coordinator talks to each shard leader, and each leader waits for a majority of its replicas before the commit becomes visible.

Figure 1 is the common skeleton. The client connects to any node; that node plans the query and acts as transaction coordinator. Each row belongs to exactly one shard, and each shard has a Raft group, typically three replicas. The leader of each affected shard appends the change to its log, replicates to followers, and acknowledges once a majority (two of three) has persisted it. Only then does the coordinator mark the transaction committed. The cost is concrete: every write pays at least one network round trip to a quorum, plus a second round for cross-shard atomicity.

Raft in one paragraph

Raft is a consensus algorithm described in the 2014 paper “In Search of an Understandable Consensus Algorithm.” A group of 2f+1 replicas tolerates f failures. One replica is elected leader per term, accepts writes, and replicates log entries; if the leader stops sending heartbeats, followers time out and elect a new one. YugabyteDB’s documentation states the replication-factor rule directly: at least 2f+1 replicas to tolerate f failed fault domains, so RF=3 survives one loss and RF=5 survives two. CockroachDB’s documentation describes the same structure: Raft groups per range, a long-lived elected leader coordinating writes, and non-voting replicas that follow the log without joining quorum.

Leaders, leases, and where reads are served

Reads are the subtle part. If any replica could answer, a partitioned follower might serve stale data. Both systems therefore route strong reads through one node per shard. CockroachDB calls it the leaseholder, and its documentation notes that leader leases, default from v25.2, tie the lease to the Raft leader so the two roles cannot diverge, removing a class of availability glitches from earlier versions. YugabyteDB’s tablet leader serves reads and writes for its tablet and relies on time-bounded leader leases so an old leader cannot answer after a new one is elected. In both, the consequence is the same: reads from a distant region cost a cross-region round trip unless you opt into follower or bounded-staleness reads.

PostgreSQL has no equivalent. Its single primary serves strong reads, and hot standbys serve reads that lag by replay delay. That simplicity is a feature: one place to ask, no shard-routing, no distributed join. You give it up only when one primary cannot carry the write rate or the failure domain.

Three Architectures Side by Side

Figure 2: Three stacks. PostgreSQL replicates one WAL stream; YugabyteDB keeps the PostgreSQL query layer over DocDB tablets; CockroachDB uses its own SQL layer over range-based storage on Pebble.

Figure 2 shows where each system draws the line between “SQL” and “storage.” It matters because the query layer is where application behavior lives, and the storage layer is where consistency lives.

PostgreSQL: one log, many readers

A PostgreSQL primary writes every change to the write-ahead log (WAL) before touching data files. Physical streaming replication sends WAL to standbys, which replay it byte for byte. Synchronous replication makes a commit wait for a standby acknowledgement, which gives zero data loss on failover at the price of latency; asynchronous replication is faster but can lose the last few transactions on promotion. PostgreSQL does not elect leaders itself. Patroni, a cloud control plane, or a Kubernetes operator uses an external consensus store such as etcd to decide who is primary.

For scale-out writes, the PostgreSQL ecosystem offers declarative partitioning, logical replication, and Citus sharding. Each works, but each shifts complexity to you: shard keys, cross-shard joins, rebalancing, and schema changes across nodes. None gives you transparent multi-region writes with strong consistency.

PostgreSQL’s strengths are the full feature surface, the extension ecosystem (PostGIS, pgvector, TimescaleDB), and the best-understood operational model in the industry. Its weakness is architectural: one writer.

YugabyteDB: PostgreSQL’s brain on a distributed spine

YugabyteDB has two layers. YSQL, the query layer, is a fork of PostgreSQL’s own code, so parser, planner, and many behaviors are inherited. Beneath it, DocDB stores data in tablets. Each table is split into tablets and each tablet is a Raft group, as the YugabyteDB replication documentation describes. DocDB itself is built on a customized RocksDB-derived storage engine, and it also serves a Cassandra-compatible API called YCQL.

Compatibility is the headline benefit. Yugabyte’s own blog says its latest versions are based on PostgreSQL 15, after a rebase from 11.2 in the 2025 releases, and that the company aims to move to a newer PostgreSQL version roughly every six months. The practical meaning: features introduced in PostgreSQL 16, 17, and 18 are not automatically available, and a PostgreSQL 18 application feature may not exist in YugabyteDB yet. Check the YugabyteDB PostgreSQL compatibility page for specifics before you rely on a newer syntax.

The licensing story is simpler than CockroachDB’s. The GitHub repository states the database components are Apache License 2.0, while the management platform is under a separate Polyform license, and default builds produce Apache-licensed binaries only.

CockroachDB: PostgreSQL wire protocol, its own engine

CockroachDB speaks the PostgreSQL wire protocol and a large dialect of its SQL, but the parser, optimizer, and storage were written in Go. Data is split into ranges, each a Raft group, stored in Pebble, a log-structured merge-tree engine written by Cockroach Labs and inspired by RocksDB and LevelDB. Because it only resembles PostgreSQL, some behaviors differ: certain extensions are unavailable, some PostgreSQL features have different semantics, and ORMs sometimes need adapters. In exchange, the team controls the whole stack, which shows in its multi-region primitives and its schema-change machinery, which runs online by design.

The architecture trade in one table

Dimension	PostgreSQL	YugabyteDB	CockroachDB
SQL layer	Native	Fork of PostgreSQL code	Own implementation, PG wire protocol
Storage	Heap plus WAL	DocDB tablets, RocksDB-derived	Pebble LSM, ranges
Replication	Physical or logical, one primary	Raft per tablet	Raft per range
Write scaling	Vertical, or sharding add-ons	Horizontal	Horizontal
Failover	External tooling	Automatic by Raft	Automatic by Raft
Core license	PostgreSQL License	Apache 2.0 core	CockroachDB Software License

Transactions, Clocks, and Isolation Levels

A transaction inside one PostgreSQL node is cheap: snapshot visibility rules and locks live in shared memory. A transaction across shards needs a protocol that survives crashes at any step. That is where the three systems, and Spanner, diverge.

Figure 3: A cross-shard transaction. The coordinator writes provisional intents to each shard, the leaders replicate them, a single commit record flips the transaction, and intents are resolved afterward.

Write intents and a single commit record

Both Yugabyte and Cockroach avoid a classic blocking two-phase commit by using provisional writes. The coordinator writes intents (uncommitted versions) to each shard through Raft. One shard holds the transaction status record. Flipping that record from pending to committed is the atomic commit point; other shards then resolve their intents asynchronously, and any reader that meets an intent can consult the status record to decide whether to see it. The design means a coordinator crash does not strand locks forever: pending transactions time out and are aborted.

The practical latency consequence is the part rarely stated. Under illustrative assumptions of 1 ms round trips inside a zone and 70 ms between two distant regions, a single-shard write whose Raft quorum stays inside one region commits in roughly one quorum round trip, a few milliseconds. The same write whose quorum must cross regions pays about a 70 ms round trip, and a cross-shard transaction can pay it more than once. These are arithmetic illustrations, not benchmarks, but they explain why placement beats tuning.

Clocks: hybrid logical clocks versus TrueTime

Ordering transactions needs timestamps. Spanner uses TrueTime, which Google’s documentation describes as a highly available distributed clock that lets applications generate monotonically increasing timestamps across all servers. Spanner’s commit protocol waits out clock uncertainty so that transaction order matches real-time order, which is called external consistency. That depends on specialized time hardware inside Google.

CockroachDB and YugabyteDB run on commodity clocks and use hybrid logical clocks (HLC), combining physical time with a logical counter. Without a TrueTime-style bound, they cannot promise full external consistency in every edge case. CockroachDB documents a maximum clock offset setting, and nodes that drift beyond it terminate themselves to avoid serving inconsistent reads; the default has historically been 500 ms, which you should confirm for your version. Production clusters therefore need disciplined time sync (chrony or cloud time services). This is an operational duty that a single PostgreSQL primary never imposed on you.

Isolation levels: what you actually get

System	Default	Also available	Notes
PostgreSQL	Read Committed	Repeatable Read, Serializable	Serializable uses SSI, aborts on dangerous structures
YugabyteDB	Read Committed from v2025.2 in new deployments; earlier versions effectively Snapshot	Snapshot, Serializable	Read Uncommitted maps to Read Committed
CockroachDB	Serializable	Read Committed	Read Committed enabled by default setting; permits non-repeatable reads, phantoms, write skew
Aurora DSQL	Snapshot, equivalent to Repeatable Read	none	Optimistic concurrency, conflicts raised at commit

The YugabyteDB row comes from its isolation levels documentation: YSQL supports Serializable, Snapshot, and Read Committed, with Read Committed on by default for new deployments from v2025.2, and it manages read-restart and conflict errors internally so clients rarely see them. CockroachDB’s Read Committed page states that Serializable remains the default and lists the anomalies Read Committed permits, along with extra lookup joins on locking reads and fully replicated locks that add latency.

The consequence for migrations is important. An application written against PostgreSQL’s default Read Committed assumes statements see the latest committed data and that conflicts block rather than abort. Moving it to CockroachDB’s default Serializable exposes it to serialization failures (SQLSTATE 40001) that must be retried by the client. Moving it to Aurora DSQL’s optimistic model exposes it to commit-time conflicts, and AWS recommends exponential backoff with jitter plus small transactions. Moving it to YugabyteDB in Read Committed mode is the closest match to what the app expects.

Treat retry logic as part of the schema of the application. If you cannot add a retry loop around every transaction, the Read Committed modes, or plain PostgreSQL, are the safer fit.

Where Aurora DSQL and Spanner fit

Amazon Aurora DSQL is the cloud-native challenger. According to AWS’s engineering blog, it is PostgreSQL-compatible rather than PostgreSQL, uses MVCC with optimistic concurrency control and backward validation, offers snapshot isolation, and advertises a 99.999 percent SLA for multi-Region setups (about 5 minutes 16 seconds of downtime a year). It supports only a subset of PostgreSQL’s feature set, and it exists only inside AWS. Google Spanner, the original, offers external consistency, a GoogleSQL dialect, and a PostgreSQL interface, and likewise exists only on Google Cloud. For readers who can accept a single cloud, these are credible alternatives to running distributed SQL yourself, and the isolation differences above apply when you compare them.

Geo-Partitioning, Residency, and Latency in Practice

Multi-region is the reason many teams look past PostgreSQL, and it is where marketing is loosest. There are three separate goals: survive a region outage, keep data inside a jurisdiction, and serve users with low latency. They pull in different directions.

Surviving a region outage needs replicas in at least three failure domains with RF=3, or five for tolerance of two. Raft needs a majority, so a two-region deployment cannot survive the loss of the larger one automatically. A third location, even a small one holding only a voting replica, is the standard fix.

Data residency needs row-level placement: rows for German customers keep all replicas in Germany. CockroachDB exposes this as regional-by-row tables, with a hidden region column deciding where each row lives, plus survival goals (zone or region) that set how many replicas exist and where. YugabyteDB achieves it with tablespaces carrying replica placement rules, combined with table partitioning, so a partition is bound to a tablespace pinned to a geography. The YugabyteDB documentation notes tablespaces as its geo-placement feature. Neither is automatic: you design the key and the partitions, and application queries must carry the partitioning column to avoid scatter-gather.

Low-latency reads lean on non-voting replicas and follower reads. CockroachDB’s documentation describes non-voting replicas that follow the Raft log without joining quorum, enabling low-latency multi-region reads with no write-latency penalty. The price is staleness: followers serve slightly old data, so you choose bounded staleness explicitly per query.

PostgreSQL’s answer is read replicas per region plus a single primary. Reads are local; writes cross the ocean to the primary unless you shard by region into separate clusters. Many data-residency requirements are satisfied more cheaply by running one independent PostgreSQL cluster per jurisdiction and routing in the application.

The summary rule: if your writes are naturally regional (a user in Frankfurt mostly writes rows that belong in Frankfurt), geo-partitioned distributed SQL delivers local-latency writes. If your writes are global to one shared row (a global inventory counter), every system pays the cross-region round trip, and no feature flag changes physics.

Asynchronous alternatives: xCluster and logical replication

Synchronous Raft across regions is not the only pattern. YugabyteDB’s xCluster offers asynchronous replication between independent clusters, trading a nonzero recovery point for write latency that never crosses regions. PostgreSQL logical replication does a similar job with more manual handling of conflicts. For disaster recovery with a tolerable loss window, asynchronous replication between two simple clusters is often cheaper and easier to reason about than a stretched cluster.

IoT and Industrial Time-Series: Where These Databases Fit

This is a site about industrial IoT and digital twins, so the practical question is whether any of these databases should store sensor telemetry. The short answer: usually not as the primary telemetry store.

Telemetry is append-heavy, time-ordered, rarely updated, and queried by time window and asset. That profile suits columnar or time-partitioned stores. Our time-series database internals comparison explains why chunked, compressed time partitioning beats general row stores for this pattern, and the industrial IoT time-series platform architecture guide shows the surrounding pipeline.

Distributed SQL is a poor default for raw telemetry because every point write pays consensus replication, storage amplification from RF=3 multiplies disk cost three times before compression, and LSM compaction competes with ingestion. The consensus guarantees you pay for are rarely needed for a temperature reading that will be averaged anyway.

Distributed SQL does fit the transactional layer around telemetry:

Asset registry and twin metadata. Device identity, hierarchy, ownership, and configuration need strong consistency and multi-site availability. Row counts are modest, updates matter, and relational integrity is valuable.
Command and control state. Desired versus reported state, firmware rollout status, and work orders are transactional and benefit from automatic failover.
Multi-site plants with residency rules. Per-region placement for plant data under regulation maps directly to geo-partitioning.
Tenant-isolated SaaS control planes. Per-tenant data with regional pinning.

A pragmatic architecture is therefore split. Raw measurements flow through MQTT or Kafka into TimescaleDB, ClickHouse, or another time-series engine, while the twin’s metadata lives in PostgreSQL or a distributed SQL cluster. If the metadata set fits one primary and one standby per site, plain PostgreSQL is the lower-risk choice, and the PostgreSQL ecosystem’s TimescaleDB extension keeps telemetry and metadata in one engine. Reach for YugabyteDB or CockroachDB when a single logical database must accept writes at multiple sites and survive losing one.

Edge sites add another constraint: a three-node Raft cluster needs three machines and a reliable network. Many factory edge deployments have one or two. Replicating from a single-node PostgreSQL at the edge up to a central cluster with logical replication or an MQTT-based sync is usually a better fit than trying to stretch consensus across the plant WAN.

Licensing and Governance Changes You Must Read

Licenses are now an architectural input.

CockroachDB. According to its licensing FAQ, all versions from 24.3.0 onward are under the CockroachDB Software License, and the old Core edition is deprecated. A paid Enterprise license supports all features and requires annual renewal. Organizations with under 10 million dollars in annual revenue (counting parents and affiliates) can use Enterprise Free, with the same functionality at no charge, but clusters are throttled after seven days without telemetry. Clusters upgrading from older versions get a 30-day grace period. In practice, a startup can run it free while telemetry is reachable; an air-gapped factory site or a large enterprise cannot assume that, and must budget for a paid license. This is no longer an open-source database, and you should read the terms with counsel, not just engineers.

YugabyteDB. The database core is Apache 2.0, per the repository. Operating it at scale may still involve the commercial management platform, YugabyteDB Anywhere, under different terms, and the vendor’s managed service. The key advantage is that you can fork, self-support, and run air-gapped without a license server.

PostgreSQL. The PostgreSQL License is a permissive BSD-style license with no vendor above it. Nobody can change the license on you, which is itself a risk-management feature.

Managed cloud options. Aurora DSQL and Spanner are proprietary services with no self-hosted path. Lock-in is the explicit price.

A useful governance question: what happens if the vendor changes terms again? PostgreSQL has no answer needed. Apache 2.0 code can be forked, though maintaining a distributed database fork is a serious burden. A proprietary license means your exit path is a migration, so plan for one from day one with standard SQL and an abstraction around vendor-specific features.

Decision Framework

Figure 4: A decision path. Start by asking whether you need more than one writer region at all; many workloads do not.

The tree encodes an opinion this article stands behind: the default winner is PostgreSQL, and distributed SQL must earn its place. A single modern PostgreSQL primary on good hardware handles a very large share of real workloads, and the operational and cognitive cost of a distributed database is paid every day, not only at scale.

Decision matrix

Scenario	Best fit	Why
Single region, under one primary’s write capacity	PostgreSQL	Simplest, full features, cheapest
Single region, needs automatic zero-touch failover	PostgreSQL with Patroni or managed, or YugabyteDB	Raft failover without external tooling if you accept PG 15 compatibility
Multi-region active-active, strict consistency	CockroachDB, Spanner	Mature multi-region primitives, Serializable default
Existing PostgreSQL app, minimal code change, scale-out	YugabyteDB	Reuses PostgreSQL query layer, Read Committed default from v2025.2
Regulated residency per country	CockroachDB or YugabyteDB	Row-level or partition-level placement
AWS-only, serverless, low ops	Aurora DSQL	Managed multi-region, but optimistic concurrency and subset of PG
Air-gapped or edge deployments	PostgreSQL or YugabyteDB	No telemetry or license server dependency
Raw sensor telemetry	Time-series engine	Distributed SQL costs more than it returns

Trade-offs, Gotchas, and What Goes Wrong

Latency is a floor you cannot tune below. Commit latency equals the slowest member of the fastest majority. A three-region cluster with one region far away still commits at the speed of the nearest two, but a placement mistake that puts two replicas far from the leader makes every write slow. Check leader and leaseholder placement regularly, and pin leaders near the writers.

Hot shards. Sequential keys, such as timestamps or auto-increment IDs, concentrate writes on one range or tablet and one Raft leader, wasting the cluster. Use hashed or UUID keys, or hash-sharded indexes, and understand that this changes the sort order that range scans expect.

Retry storms. Under Serializable or optimistic concurrency, contention produces aborts. Naive immediate retries amplify load. Use exponential backoff with jitter, as AWS recommends for Aurora DSQL, and keep transactions short.

Clock problems. HLC systems tolerate bounded skew only. A VM pause, an NTP step, or a drifting host can push a node past its allowed offset. Monitor clock offset as a first-class metric.

Compatibility surprises. YugabyteDB lags the latest PostgreSQL; CockroachDB differs in extensions and some semantics; Aurora DSQL supports a subset. Run your actual test suite and your actual ORM’s migrations before you decide. Extensions such as PostGIS and pgvector are the usual blockers, so check their status on each platform.

Operational cost. A three-node Raft cluster has three times the storage, background compaction, rebalancing traffic, and an upgrade process that is rolling but nontrivial. The team needs skills in a database that few engineers know deeply.

Majority loss is still an outage. Distributed does not mean indestructible. Lose two of three replicas of a shard and it is unavailable until recovered. Backups and tested restores remain mandatory.

Practical Recommendations

Start from the workload, not the brand. Measure how close one PostgreSQL primary is to its limits: write rate, replication lag, and recovery time during a failover drill. If headroom remains, spend effort on partitioning, connection pooling, and a tested Patroni or managed failover before adopting a distributed engine.

If you do need distributed SQL, run a time-boxed proof of concept on your own schema and your own client library. Test the three things that decide outcomes: transaction retry behavior under contention, failure injection (kill a node, then a zone, then partition a region), and the cost of your real query mix across your real regions. Do not accept a vendor benchmark as a substitute.

Choose YugabyteDB when PostgreSQL compatibility and an open Apache core matter most and you can live with PostgreSQL 15 era features. Choose CockroachDB when multi-region survival goals and mature regional table semantics matter and the license terms fit your organization. Choose a cloud service when one cloud is acceptable and you want the operations handled for you.

Checklist before you commit:

Confirm current versions and licenses on the vendor pages (this article is dated October 2026).
Verify required extensions and ORM features on the target platform.
Pick keys that avoid hot shards, and test them with realistic load.
Add retry loops with backoff and jitter around every transaction.
Place leaders near writers and verify with metrics.
Monitor clock offset, replication lag, and compaction backlog.
Rehearse restore from backup and a full-region failure.
Write down the exit plan in case licenses or pricing change.

Frequently Asked Questions

Is YugabyteDB just PostgreSQL?

No. YugabyteDB reuses PostgreSQL’s query-layer code, but replaces storage with DocDB, which shards data into Raft-replicated tablets. That gives horizontal write scaling and automatic failover, but it also means behavior and performance differ from a single PostgreSQL node. Its documentation and blog state the current base is PostgreSQL 15, so newer PostgreSQL features may be missing, and some extensions or features behave differently. Always test your workload rather than assuming drop-in equivalence.

Is CockroachDB still open source in 2026?

No, not in the traditional sense. Per Cockroach Labs’ licensing FAQ, versions from 24.3.0 onward use the CockroachDB Software License, and the Core edition is deprecated. Enterprise features require a paid license, while organizations under 10 million dollars in annual revenue can use a free Enterprise tier that requires telemetry. The source of earlier releases remains available under earlier licenses, but you should read the current terms before building a product or an air-gapped deployment around it.

Which is faster, PostgreSQL or a distributed SQL database?

On a single node, PostgreSQL is usually faster per transaction because it never waits on a network quorum. Distributed SQL trades that latency for horizontal write scaling, automatic failover, and multi-region placement. The right comparison is not raw speed but whether one primary can meet your write rate and recovery needs. Published benchmarks vary widely with hardware, isolation level, and topology, so run your own test on your schema before deciding.

What isolation level should I use?

Use the strongest level your latency budget allows, and make the application retry. CockroachDB defaults to Serializable and supports Read Committed. YugabyteDB defaults to Read Committed from v2025.2 and supports Snapshot and Serializable. PostgreSQL defaults to Read Committed. Aurora DSQL offers snapshot isolation only. If you cannot add retry logic, prefer Read Committed behavior or plain PostgreSQL, and be aware of write skew and other anomalies that weaker levels allow.

How do Aurora DSQL and Spanner compare with self-managed options?

Both are managed, proprietary, and tied to one cloud. Aurora DSQL is PostgreSQL-compatible with snapshot isolation, optimistic concurrency, and a stated 99.999 percent multi-Region SLA, but supports a subset of PostgreSQL. Spanner offers external consistency through TrueTime and a PostgreSQL interface. They remove operational burden and clock management but remove portability too. Self-managed YugabyteDB or CockroachDB keeps you cloud-neutral at the cost of running consensus clusters yourself.

Should I store IoT sensor data in distributed SQL?

Usually no. Raw telemetry is append-heavy and time-ordered, which suits time-series engines such as TimescaleDB or ClickHouse far more than Raft-replicated row stores that triple write and storage cost. Use distributed SQL, if you need it at all, for transactional metadata: device registry, twin configuration, and command state across sites. Many deployments are best served by PostgreSQL for metadata plus a dedicated time-series store for measurements.

PostgreSQL vs YugabyteDB vs CockroachDB (2026): Which Wins