Stonebraker Warns Postgres Lags Rivals 10x at Scale, Rejects GPUs

Ryan Peterman

General-purpose databases surrender an order-of-magnitude performance edge to specialized engines on heavy workloads, while GPU acceleration fails because pointer-chasing index traversals break SIMD architecture.

AI-assisted summary of Creator of Postgres (Turing Award): "One Size Fits None", Leveraging GPUs, Difficult Implementations — original source. Check the original for full context.

Source published: 2026-09-17

Key ideas

Specialized database architectures consistently outperform general-purpose relational engines by an order of magnitude (10×) on targeted workloads such as stream processing, columnar analytics, and vector search. (0:00)
Postgres functions as an ideal default for initial development due to its rich ecosystem and talent pool, but it breaks down at high thresholds like 1,000,000 transactions per second or petabyte-scale data warehousing. (0:00)
GPUs struggle with standard database indexing because their SIMD architecture is incompatible with sequential pointer-chasing across B-tree levels, and they face severe interconnect bus bottlenecks. (3:18)
When building Ingres from the ground up, the query optimizer proved to be the single most difficult engineering challenge due to its inherent algorithmic complexity. (5:00)

Detailed notes

## Background Published on YouTube by Ryan Peterman on September 16, 2026, this clip is drawn from an extended interview with Turing Award recipient and Postgres creator Mike Stonebraker. The video description notes that the segment focuses on Stonebraker's architectural philosophy of database design, the viability of leveraging GPUs, and the hardest components to implement from scratch.

## TL;DR Mike Stonebraker argues that 'one size fits none' in data management, noting that specialized engines like column stores and vector databases routinely beat general-purpose row stores by an order of magnitude. While acknowledging Postgres as the unrivaled, cost-effective default for low-to-mid-tier workloads, he highlights its scaling limits in large data warehouses lacking native columnar storage or built-in clustering. He also pushes back on GPU database acceleration, explaining that B-tree indexing relies on sequential pointer chasing that is fundamentally incompatible with SIMD parallelism and choked by interconnect bottlenecks. Concluding with his work on Ingres, Stonebraker singles out the query optimizer as the most algorithmically difficult component to build from scratch.

## Atmosphere & style The discussion has the measured, no-nonsense weight of a seasoned systems pioneer dismantling modern software hype with core architectural reality. Stonebraker delivers his insights with direct, unvarnished pragmatism, casually breaking down abstract performance debates into tactile hardware realities like bus bottlenecks and pointer traversals. Hosted in a concise, interview-driven format, the exchange feels like an intimate masterclass in computer systems engineering where practical experience decisively trumps prevailing industry trends.

## Bulletin - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Specialized database architectures consistently outperform general-purpose relational engines by an order of magnitude (10×) on targeted workloads such as stream processing, columnar analytics, and vector search. - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Postgres functions as an ideal default for initial development due to its rich ecosystem and talent pool, but it breaks down at high thresholds like 1,000,000 transactions per second or petabyte-scale data warehousing. - [03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) GPUs struggle with standard database indexing because their SIMD architecture is incompatible with sequential pointer-chasing across B-tree levels, and they face severe interconnect bus bottlenecks. - [05:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=300s) When building Ingres from the ground up, the query optimizer proved to be the single most difficult engineering challenge due to its inherent algorithmic complexity.

## Key takeaways - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) The premise that 'one size fits all' in database architecture is fundamentally flawed; in practice, general-purpose designs sacrifice an order of magnitude in performance. - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Historical architectures like StreamBase for stream processing and Vertica for column-based data warehousing demonstrated 10× speedups over standard relational row stores. - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Modern engines like ClickHouse and Pinecone continue to outperform traditional relational databases retrofitted with user-defined types (UDTs). - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Native column storage and built-in multi-node distributed clustering are minimum requirements for data warehousing that Postgres lacks. - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) Postgres is the undisputed default starter database because it is free, widely supported, and easy to hire engineers for. - [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) The viability of Postgres as a general-purpose solution ends when hitting massive scale, such as petabyte-scale analytics or one million transactions per second. - [03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) GPU SIMD execution models are fundamentally ill-suited for database indexing, which relies on avoiding scans rather than uniform bulk compute. - [03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) Transferring data across the interconnect bus between storage, host CPUs, and GPUs creates a major hardware bottleneck that undermines GPU acceleration. - [03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) B-tree traversal relies on sequential, non-contiguous pointer chasing three to four levels deep, making it impossible to effectively parallelize across SIMD lanes. - [05:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=300s) The original Ingres relational database was implemented entirely from scratch without modern pre-existing data structure libraries. - [05:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=300s) Developing the query optimizer was the most difficult part of Ingres due to the algorithmic complexity of join orders, execution paths, and query trees.

## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) "One Size Fits None": Specialized Engines vs. Postgres as the Baseline

The discussion opens around the philosophy behind Mike Stonebraker’s seminal 2005 paper, which argued that "one size fits all" database systems are fundamentally sub-optimal—in reality, "one size actually fits none." Recalling the state of research around 2004, Stonebraker points out that his team was running an academic project building what eventually became StreamBase. A dedicated stream processing engine looks absolutely nothing like a classic relational row store. At the very same time, they were developing the core ideas behind column stores for data warehouses, which was later commercialized as Vertica. Column stores and row stores share virtually no architectural DNA. In every category, these purpose-built engines were an entire order of magnitude faster than traditional general-purpose relational engines attempting to handle the same workloads.

Stonebraker stresses that this architectural reality has not changed at all today: running a system that was not designed for your specific workload forces you to sacrifice an order of magnitude in performance. Modern architectures prove the rule: ClickHouse dominates analytics as a purpose-built column store, while dedicated vector databases like Pinecone dramatically outperform user-defined types (UDTs) retrofitted into relational engines for vector processing. While it is technically straightforward to place a single unified parser on top of multiple distinct underlying engine implementations, Postgres has historically chosen not to do this. Because Postgres does not implement a native column store or built-in multi-node distributed clustering—capabilities Stonebraker calls simple "table stakes" for sizable data warehouses—it cannot compete at massive warehouse scale.

Nonetheless, Stonebraker readily concedes the unmatched utility of Postgres at the low end. For developers who simply need to get a project off the ground, Postgres remains the obvious default choice. It is free, backed by a massive global developer ecosystem with endless custom data type extensions, and finding engineering talent who know Postgres is trivial. It serves as an exceptional lowest common denominator that works seamlessly until an application pushes boundaries—such as demanding a million transactions per second or handling a petabyte-scale data warehouse. At that lower end, Postgres genuinely acts as an effective one-size-fits-all solution; at the high end, that claim completely breaks down.

- **Historical Precedents (circa 2004):** StreamBase (stream processing) and Vertica (C-Store column-oriented warehousing) proved specialized designs deliver a 10× (order of magnitude) speed advantage over standard row stores. - **Modern Counterparts:** ClickHouse (columnar analytics) and Pinecone (dedicated vector search) outperform general relational databases and custom UDTs on their respective tasks. - **Postgres Limitations at Scale:** Lacks a native column store and built-in multi-node clustering, disqualifying it from large enterprise data warehousing. - **The Postgres Sweet Spot:** Unbeatable as a starter system due to zero cost, deep talent pools, and wide data type support, functioning well until hitting thresholds like 1,000,000 transactions per second or petabyte-scale datasets.

---

[03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) GPUs in Databases: SIMD Bottlenecks and the Anathema of Indexing

When asked whether GPUs offer fresh opportunities to accelerate and optimize databases, Stonebraker responds cautiously. While there may be niche applications, the fundamental architectural mismatch is that GPUs are built around SIMD (Single Instruction, Multiple Data) execution models, which he describes as "the anathema of indexing." Whenever database performance relies on indexes to avoid scanning whole tables, GPU acceleration typically ceases to be a good design choice. Furthermore, deploying GPUs as accelerators attached to host CPUs creates severe hardware bottlenecks, as storage throughput and the interconnect bus (such as PCIe) between the CPU and GPU frequently choke data flow before the compute cores can even be utilized.

To illustrate why SIMD execution fails when indexing, Stonebraker uses the concrete example of searching for Ryan’s salary in a B-tree index. To locate a record, the database begins at the root of the B-tree, evaluates keys to find the divider containing the search target, and follows a pointer to the next child node. Following that pointer requires an unpredictable, non-contiguous memory access. The engine repeats this traversal three or four levels down the tree until reaching the leaf node. Because tree traversal consists of dependent, sequential pointer chasing rather than uniform operations across large contiguous blocks of data, it cannot be effectively parallelized across wide SIMD lanes.

```mermaid flowchart TD accTitle: B-Tree Pointer Chasing vs SIMD Parallelism accDescr: Flow diagram showing how sequential B-tree pointer traversals conflict with GPU SIMD execution.

subgraph GPU["GPU Execution Profile"] SIMD["SIMD Cores: Require uniform, contiguous operations"] Bus["Interconnect Bus: Storage-to-GPU transfer bottleneck"] end

Traversal -.->|"Incompatible with"| SIMD ```

- **GPU Hardware Constraints:** SIMD hardware excels at identical instructions across uniform memory blocks, whereas tree indexing requires branchy, scalar pointer jumps. - **Bandwidth Limitations:** Moving data across the system bus connecting storage, CPU, and GPU often becomes the primary performance bottleneck. - **Pointer Chasing Mechanics:** B-tree lookups require three to four dependent memory accesses in sequence, inherently resisting SIMD vectorization.

---

[05:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=300s) Building Ingres from Scratch and the Query Optimizer Challenge

Reflecting on the early era of relational database research, Ryan Peterman asks whether the original implementation of Ingres required writing every single component by hand—including fundamental data structures like B-trees—given the lack of modern pre-packaged libraries. Stonebraker confirms that the original Ingres system was built entirely from scratch from the ground up.

When asked what proved to be the single hardest part of that entire implementation, Stonebraker answers without hesitation: the query optimizer. Developing an optimizer that could accurately evaluate query trees, project join orders, and select execution paths proved exceptionally demanding because the problem is fundamentally and "algorithmically difficult."

## Notable quotes > [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) one size actually fits none — Mike Stonebraker

> [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) running a system that was not designed for your specific workload forces you to sacrifice an order of magnitude in performance — Mike Stonebraker

> [00:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=0s) table stakes — Mike Stonebraker

> [03:18](https://www.youtube.com/watch?v=qCKgWsexY6c&t=198s) the anathema of indexing — Mike Stonebraker

> [05:00](https://www.youtube.com/watch?v=qCKgWsexY6c&t=300s) algorithmically difficult — Mike Stonebraker

## Mentioned Mike Stonebraker, Ryan Peterman, Postgres, StreamBase, Vertica, C-Store, ClickHouse, Pinecone, Ingres

## Video description This is a clip from the full conversation with Mike Stonebraker (Creator of Postgres, Turing Award Winner for work in databases): https://www.youtube.com/watch?v=YPObBOwIrHk

[Source](https://www.youtube.com/watch?v=qCKgWsexY6c)

中文简报

Stonebraker警告Postgres在大规模场景落后竞品10倍，并不看好GPU加速在重负载场景下，通用数据库相比专用引擎会损失一个数量级的性能优势；而由于指针追踪式的索引遍历破坏了SIMD架构，GPU加速同样难以奏效。 Mike Stonebraker指出，在数据管理领域“通用即不适用”，列存和向量数据库等专用引擎在特定工作负载下的性能通常能高出通用行存数据库一个数量级。尽管他承认Postgres是低至中等负载下无可匹敌且具成本效益的默认选择，但他强调，在缺乏原生列式存储或内置集群功能的大型数据仓库中，Postgres存在扩展局限。他还对GPU数据库加速提出了反驳，解释称B树索引依赖顺序指针追踪，这从根本上与SIMD并行机制不兼容，并受制于互连瓶颈。最后结合他在Ingres上的研发经历，Stonebraker指出查询优化器是从零构建数据库时在算法层面上最困难的组件。专用数据库架构在流处理、列式分析和向量搜索等特定工作负载上，性能持续比通用关系型引擎高出一个数量级（10倍）。 (0:00) 凭借丰富的生态系统和人才储备，Postgres是初期开发的理想默认选择，但在达到每秒100万次事务或PB级数据仓库等极高门槛时会遭遇瓶颈。 (0:00) GPU在应对标准数据库索引时表现不佳，原因是其SIMD架构与跨B树层级的顺序指针追踪不兼容，且面临严重的互连总线瓶颈。 (3:18) 从零开始构建Ingres时，由于固有的算法复杂性，查询优化器被证明是难度最大的单一工程挑战。 (5:00)

Reading summary

Database pioneer Mike Stonebraker argues that general-purpose database architectures sacrifice an order of magnitude in performance compared to specialized engines at high scale, though Postgres remains the pragmatic default for smaller workloads. He also contends that GPU acceleration is fundamentally mismatched with core database operations like indexing. Specialization Versus the Postgres Baseline (0:00) Stonebraker maintains his 2005 thesis that 'one size actually fits none' in data management. Specialized architectures—such as StreamBase for streaming data and Vertica for column-oriented analytics around 2004—demonstrated an order-of-magnitude (10×) speed advantage over standard relational row stores. In modern environments, dedicated engines like ClickHouse for columnar analytics and Pinecone for vector processing similarly outperform general-purpose relational systems and retrofitted user-defined types (UDTs). Despite these performance penalties at high scale, Stonebraker highlights Postgres as an exceptional lowest common denominator for starting projects. Because it is free, widely understood by developers, and supported by a vast ecosystem with extensive custom data types, it functions effectively until an application demands extreme throughput, such as one million transactions per second, or manages petabyte-scale data warehouses that require native column stores and multi-node clustering. Hardware Bottlenecks and GPU Indexing Mismatch (3:18) Stonebraker expresses skepticism regarding the broad application of GPUs to accelerate databases, labeling the SIMD (Single Instruction, Multiple Data) execution model as 'the anathema of indexing.' Database performance predominantly relies on indexes to avoid scanning entire datasets, but tree-based indexing resists vectorization. For instance, locating a record in a B-tree index requires sequential, branchy pointer chasing across three or four hierarchical levels with unpredictable, non-contiguous memory lookups rather than uniform operations over contiguous blocks. In addition to algorithmic divergence, hardware interconnects present a major constraint. When GPUs operate as accelerators alongside host CPUs, transferring data across the system bus from storage to the GPU frequently saturates bandwidth, forming a bottleneck before compute cores can be effectively leveraged. Algorithmic Complexity in Early Query Optimizers (5:00) Recalling the early development of the Ingres relational database, Stonebraker notes that the system had to be built from scratch without existing foundational software libraries, requiring manual implementation of structures like B-trees. Among all the components developed from the ground up, he identifies the query optimizer as the single most difficult engineering challenge. Correctly evaluating query trees, determining optimal join orders, and selecting execution paths remained an exceptionally demanding task due to the fundamental, algorithmic difficulty of the problem. While purpose-built architectures dominate specialized workloads and massive scale, general-purpose relational databases like Postgres retain widespread adoption by balancing lower-end operational simplicity against peak performance.

Source quotes

[0:00] Mike Stonebraker: one size actually fits none [0:00] Mike Stonebraker: running a system that was not designed for your specific workload forces you to sacrifice an order of magnitude in performance [0:00] Mike Stonebraker: table stakes [3:18] Mike Stonebraker: the anathema of indexing [5:00] Mike Stonebraker: algorithmically difficult

Original transcript

[0:00] talk and I think there's also a paper [0:01] behind it of this idea that uh one [0:05] sizefits all database systems not [0:07] optimal one size actually fits none and [0:10] that what you really want is database [0:14] solutions that target specific needs [0:17] what database offerings you see today [0:19] that are one-sizefits-all in 2004 when I [0:22] wrote the paper we had an academic [0:25] project which was building what became [0:28] streambase [0:29] And so a stream processing engine looks [0:32] nothing like a relational database. [0:36] And we had the gist of an idea for [0:39] column stores for the for data [0:41] warehouses which was popularized by [0:44] Vertica looks nothing like a row store. [0:48] So here were three wildly different [0:50] implementations that had no resemblance [0:53] to each other and in each case they were [0:56] an order of magnitude faster than the [0:59] other guys. So it's pretty clear that [1:02] one side, you know, that in with those [1:04] three instances, [1:06] you give up an order of magnitude [1:09] uh when you're running a database system [1:12] that isn't [1:14] that isn't architected for your kind of [1:17] stuff. I think that's still true. I [1:20] mean, I think Clickhouse is a column [1:23] store. Pine cone is faster than [1:28] userdefined types [1:31] on on textbased vector processing. [1:36] And so I think it's it's still very much [1:39] the case [snorts] and I think [1:43] there's no difficulty [1:46] putting a common parser on top of [1:48] multiple implementations. [1:51] uh Postgress has so far chosen not to do [1:54] that. they don't implement a column [1:57] store [1:59] and so I think they are not they are not [2:01] competitive you know on sizable data [2:05] warehouses [2:07] they also don't have multi-node support [2:11] again for people with big data [2:13] warehouses that's table stakes so I [2:16] think it's just as true today as it ever [2:18] was I think that [2:22] what is true [2:24] is that if you want to get going, you [2:26] have a database problem, [2:29] you know, the answer is choose Postgress [2:32] [snorts] and there's a huge programming [2:34] community, all kinds of all kinds of, [2:38] you know, data type implementations. [2:40] it's free uh and you can find Postgress [2:46] talent easily and get going [2:49] and and so I think it's it's it's a [2:52] great choice for lowest common [2:54] denominator [2:56] and until you're trying to do [snorts] a [3:00] million transactions a second it works [3:02] just fine until you're trying to support [3:06] a pedibyte data warehouse it it I say at [3:08] the low end it it's absolutely [3:10] Absolutely the right one sizefits all at [3:12] the low end it's postgress at the high [3:15] end that's just not true [3:18] >> GPUs do they make available some new [3:21] opportunities to optimize databases [3:24] probably but I think the the big [3:27] challenge is that GPUs are [3:32] you know sumd sim you know single [3:34] instruction multi- data and that's [3:37] that's the anathema of indexing [3:41] And so whenever indexing is the right [3:43] answer, [3:44] they're probably not a good idea. [3:48] And I think uh also you've got to [3:52] architect them so that the so that the [3:56] bandwidth [3:58] so that the bandwidth from storage is is [4:02] not not the bottleneck. And so if [4:06] they're an add-on to the CPU as often as [4:09] not the bus connecting it to the the GPU [4:12] to the CPU is a bottleneck. [4:15] >> Can you explain why indexing would be [4:18] not as effective when there's SIMD? [4:22] >> So let's let's say I'm I'm [snorts] [4:26] looking for Ryan's [4:29] I'm looking for Ryan's salary and I have [4:31] a B tree. [4:33] So you go to the root of the B tree. [4:37] You find you find the divider that has [4:41] both sides of Ryan. [4:43] You follow the pointer. [4:46] That's a memory access for sure. Then [4:49] you do it all again and you do this like [4:52] three or four times. [4:54] So that doesn't parallelize well. So the [4:57] answer is indexing doesn't parallelize [4:59] well. You mentioned B trees. When you [5:01] first implemented [5:03] uh that first version of ingress, did [5:06] you write all of that by hand? Because I [5:08] imagine there's probably not some [5:10] existing B tree library or something. [5:13] >> Yeah, we wrote the original version of [5:15] ingress was all written from scratch. [5:17] >> What was the hardest part of that [5:19] implementation? [5:21] >> Uh query optimizer. [5:23] >> And why was that hard? [5:25] >> It's tough. It's it's just [5:29] algorithmically difficult.