
DB Weekly: lock convoys and column stores
This week’s brief frames the database trade-off around workload boundaries: Postgres remains the transactional default, but lock-convoy incidents, Postgres-to-ClickHouse migration outcomes, and DuckDB-in-MySQL experiments show where specialized columnar execution starts to matter. It also covers vector DB stability releases, managed-platform control-plane shifts, and the MySQL 8.0 support deadline.
The practical database decision from July 6-13 is boundary placement. PostgreSQL still looks like the default transactional center, but the highest-signal material came from places where normal row-store strengths turned into limits: lock convoys, high-volume cache reads, OLAP scans, and vector-search release risk.
| Decision area | What changed | Engineering read |
|---|---|---|
| Postgres contention | Recall.ai documented a production incident where 15,000 bot processes waited on a single GIN index extension lock, driving the database to 100% CPU system time for hours. 1 | Treat synchronized write bursts and retry behavior as design inputs, not only incident-response details. |
| Analytical offload | Momentic moved a cache workload from PostgreSQL to ClickHouse and reported more than 2 million cache queries per day, about 20 billion cache entries per day, and roughly 250 ms average resolution latency. 2 Percona's experimental DuckDB MySQL storage engine completed all 22 TPC-H SF10 queries in 15.1 seconds, while InnoDB took 1,317 seconds and completed 16 of 22 within the test cap. 3 | Columnar execution is no longer an abstract "maybe later" option for mixed estates, but the workload shape has to match. |
| Vector search | pgvector v0.8.5 reduced IVFFlat build memory for small tables, and Weaviate v1.38.3 shipped roughly 80 fixes without breaking changes. 4 5 | For vector infrastructure, stability releases and benchmark reproducibility matter more than feature count. |
| Managed database surface | MongoDB Atlas Gen2 on AWS claims 15-20% lower CPU utilization and about 45% lower read and write latency for M30+ dedicated clusters, while Supabase added searchable field-level encryption through CipherStash. 6 7 | Managed platforms are moving more control-plane and security work out of application code. That can reduce migration work, but it increases provider-specific dependency. |
| Support deadline | MySQL 8.0 standard support ends on July 31, 2026, and Percona says Extended Lifecycle Support covers high-severity CVE fixes for MySQL 5.7 and 8.0. 8 AWS RDS Extended Support provides up to three years of critical and high CVE security updates and bug fixes. 9 | The decision is now support bridge versus upgrade plan, not whether the deadline is real. |
Lock behavior is a selection input
Recall.ai's incident is useful because it is specific enough to test against. The failure started when about 15,000 bot processes wrote
BotEvent rows at the top of the hour, forcing concurrent GIN index extension and creating a lock queue on a single index extension path. 1 The second failure mode came from deadlock detection: many backends woke up on the same cadence, competed for 16 lock-manager partition locks, and spent CPU proving that relation extension locks could not participate in the deadlock cycle. 1The operational lesson is narrower than "Postgres locks do not scale." It is that evenly scheduled application work can defeat otherwise reasonable database behavior. Teams with cron-like fan-out, webhook replay, meeting-bot ingestion, or bulk status transitions should test the lock path under synchronized load, especially when GIN indexes, write bursts, and high connection counts meet in the same table.
PlanetScale's deadlock piece gives the application-side companion. PostgreSQL runs deadlock detection after
deadlock_timeout, which defaults to 1 second, and cancels one transaction when it finds a cycle. 10 Applications that immediately retry the killed transaction can recreate the same cycle; the concrete mitigation is to catch SQLSTATE 40P01 and retry with backoff and jitter. 10The pgrust discussion shows how much interest these limits are attracting. pgrust, a Rust rewrite of PostgreSQL, says it now passes 100% of the PostgreSQL regression tests, and the Hacker News thread drew 819 points and 723 comments. 11 Michael Malis, the pgrust author, argues that PostgreSQL's outage-prone areas include VACUUM and transaction ID wraparound, connection limits from the process model, poor query plans, and JSON behavior. 12 That is not a reason to move production systems to a rewrite. It is a useful checklist for stress tests that normal happy-path benchmarks often miss.
Columnar offloads are now concrete options
Momentic, an AI-driven software testing platform, is the strongest migration case this week. Its cache table grew from about 80,000 rows to 1 billion rows, and the PostgreSQL design started hitting elevated resource usage and lock contention under high-read and high-write load. 2 The migration path was conservative: dual-write to PostgreSQL and ClickHouse, run background shadow queries, diff the results, gradually shift production traffic, and only then stop writing to PostgreSQL. 2
The interesting part is not just that ClickHouse was faster. Momentic changed the data model to fit ClickHouse. Feature-branch queries, which made up about 90% of cache lookups, could use ClickHouse's sparse primary index efficiently; main-branch outlier queries needed a materialized view over commit timestamps. 2 ClickHouse's ReplacingMergeTree engine let Momentic replace UPDATE operations with INSERT patterns and remove Redis from the cache path. 2
That makes the case more transferable than a raw benchmark. The pattern is: immutable or append-friendly data, known lookup keys, high read volume, high write volume, and tolerance for columnar modeling. If the workload depends on many small transactional updates, broad ad hoc point lookups, or strict row-level mutation semantics, the Momentic result is a warning to model first and benchmark second.
Percona's DuckDB-as-MySQL engine points at the same boundary from the MySQL side. The experimental
ducksdb-mysql-engine lets a table marked ENGINE=DuckDB execute analytical queries through DuckDB instead of InnoDB. 3 On TPC-H SF10 with a 60 million-row lineitem table, the DuckDB engine completed all 22 queries in 15.1 seconds; InnoDB took 1,317 seconds and finished only 16 of 22 queries within the 180-second cap. 3 At SF100 with a 600 million-row lineitem table, Percona reported correct results for all 22 queries, with performance close to native DuckDB. 3The constraint is just as important as the result. Percona labels the integration experimental, GPLv2, and not production-grade. 3 For architecture planning, this belongs in the evaluation bucket with MariaDB+DuckDB-style HTAP experiments: promising for analytic pushdown, not a reason to run business-critical MySQL tables on a new storage engine next week.
Vector DBs: stability work beats winner claims
The vector stack delivered mostly maintenance and benchmark interpretation work. pgvector v0.8.5, released July 8, reduced memory usage for small-table IVFFlat index builds. 4 Its previous v0.8.4 release fixed an
hnsw graph not repaired error during HNSW vacuuming, possible insert errors during HNSW vacuuming, and IVFFlat index-build memory exceeding maintenance_work_mem. 4 For teams using Postgres as the vector layer, those are operational fixes, not selection-changing features.Weaviate v1.38.3 is the broader stability release. It shipped on July 10 with roughly 80 fixes, no breaking changes, BM25 optimization work, async-replication hardening, HNSW fixes, backup fixes, RBAC fixes, queue recovery changes, and an HFresh
searchProbe default increase to 256. 5 Weaviate also shipped v1.37.12 as a backport with about 45 fixes and v1.36.21 with 12 fixes. 13 14 Operators on older Weaviate branches should read those backports as active maintenance signals, not as permission to skip their own regression tests.Qdrant's benchmark post is useful only if treated as a starting hypothesis. Qdrant claimed that its vector search achieved twice Elastic DiskBBQ's throughput, half the latency, and one-third the compute in its published test. 15 That kind of claim should trigger a reproduction plan with your filter mix, segment sizing, disk profile, recall target, and ingestion pattern. It should not end a selection process.
Chroma and LanceDB send different rollout signals. Chroma's latest stable release remained v1.5.9 from May 5, while its dev pipeline reached 1.5.10.dev198 on July 12, creating a 69-day stable-release gap with visible pre-release activity. 16 LanceDB shipped Node/Rust v0.32.0-beta.0/1 and Python v0.35.0-beta.0/1 on July 10, including an elastic dataloader, Tencent COS and GooseFS support, OpenTelemetry metrics, LSM write-spec reading, and a breaking change aligning
Permutation.with_format("torch") with Hugging Face set_format("torch"). 17 Stable-cut cadence and SDK compatibility should be part of vector DB selection, especially for teams already carrying model-serving and embedding-pipeline risk.Managed platforms are moving the control plane
MongoDB's strongest update is operational rather than semantic. Atlas Gen2 on AWS for M30+ dedicated clusters uses ARM-based processors, claims 15-20% lower CPU utilization, about 45% lower read and write latency, and independent IOPS scaling from storage. 6 MongoDB says Gen2 became generally available on June 30 for eligible Atlas customers in select AWS regions and does not require application changes, migrations, or rearchitecture. 6
The selection implication is simple: this is an Atlas cost and performance lever before it is a database-design change. If an Atlas estate is CPU-bound or overprovisioning storage to buy IOPS, Gen2 deserves a controlled before-and-after test. If the workload is schema, index, or query-shape bound, the processor change will not remove that work.
MongoDB also moved Search and Vector Search beyond Atlas. MongoDB Search and Vector Search reached general availability for Enterprise Advanced and Community Edition on July 1, making previously Atlas-only search capabilities available in self-managed deployments. 18 That changes the trade-off for teams that rejected Atlas for sovereignty, network, or operational-control reasons but still wanted integrated full-text and vector search.
Supabase and CipherStash pushed the security boundary into the query path. The integration encrypts sensitive fields at the application layer with a unique key per value, supports search and joins over encrypted data, and uses ZeroKMS so neither Supabase nor CipherStash can access plaintext. 7 The useful test is not whether searchable encryption sounds attractive. The test is whether policy-at-decryption, proxy access over the PostgreSQL wire protocol, and SDK support for Supabase.js, Drizzle, and Prisma fit the team's threat model and operational path. 7
Neon and Redis both moved ergonomics up a layer. Neon shipped
@neon/sdk on July 13 as a fetch-based, zero-dependency, ESM-only TypeScript client generated from its OpenAPI spec, with workflows for createAndConnect, snapshot restore preview, project transfer, and branch creation with compute. 19 Redis Data Integration reached general availability in Redis Cloud on AWS, supporting MongoDB and previewing Snowflake, while Redis Flex added tunable RAM-to-Flash ratios from 10% to 50% and BYOC pricing. 20 These changes reduce glue code. They also make provider APIs and managed pipelines part of the system's portability story.Cross-engine positioning and action queue
The market signal still favors PostgreSQL momentum, but it does not erase workload-specific MySQL reasons. DB-Engines' July 2026 ranking put PostgreSQL at 687.80, up 6.92 year over year, and MySQL at 846.46, down 94.27 year over year; PostgreSQL was the only top-four database with a positive year-over-year score. 21 That makes PostgreSQL the stronger default for greenfield general-purpose systems, but the MySQL estate still has to be managed on deadlines, support contracts, and application compatibility.
- Test synchronized write bursts, not just average throughput. Recall.ai's failure depended on 15,000 processes converging on the same lock path, and PlanetScale's retry-storm warning shows how application behavior can keep a database-level deadlock alive. 1 10
- Evaluate ClickHouse or DuckDB offload only after naming the workload shape. Momentic's case fits high-volume cache lookups and append-friendly modeling; Percona's DuckDB result fits analytical scans and remains experimental. 2 3
- For vector databases, prioritize branch maturity and benchmark reproduction. pgvector and Weaviate shipped operational fixes, Qdrant published a strong vendor benchmark claim, Chroma is between stable cuts, and LanceDB is in a beta wave. 4 5 15 16 17
- Decide the MySQL 8.0 path before July 31. Percona ELS and AWS RDS Extended Support can buy time, but they are support strategies, not modernization plans. 8 9
- Treat managed-platform features as architecture dependencies. Atlas Gen2, MongoDB self-managed Search and Vector Search, Supabase CipherStash, Neon SDK, and Redis RDI all move useful work out of application code; each one should be evaluated with rollback, portability, and observability requirements written down. 6 18 7 19 20
Cover image: image from Momentic, "How We Ditched Postgres for ClickHouse to Process 12 Billion Caches Per Day".
Fuentes de referencia
- 1Recall.ai: Postgres locks do not scale
- 2Momentic: How We Ditched Postgres for ClickHouse to Process 12 Billion Caches Per Day
- 3Percona: Running DuckDB as a MySQL 9.7 storage engine
- 4pgvector CHANGELOG.md
- 5GitHub: Weaviate v1.38.3
- 6MongoDB: Introducing Atlas Gen2 on AWS for M30+ Dedicated Clusters
- 7Supabase: Searchable field-level encryption on Supabase with CipherStash
- 8Percona: Still on MySQL 5.7 or 8.0? Those high-severity CVE fixes are covered
- 9AWS: Amazon RDS Extended Support
- 10PlanetScale: Deadlocks and downtime
- 11Hacker News: Postgres rewritten in Rust, now passing 100% of the Postgres regression tests
- 12malisper.me: The four horsemen behind thousands of Postgres outages
- 13GitHub: Weaviate v1.37.12
- 14GitHub: Weaviate v1.36.21
- 15Qdrant: Qdrant Beats Elastic's DiskBBQ at 2x Throughput, Half the Latency, and 1/3 the Compute
- 16GitHub: Chroma Releases
- 17GitHub: LanceDB Releases
- 18MongoDB: MongoDB Search and Vector Search Now Run Anywhere
- 19Neon: Introducing @neon/sdk, our new TypeScript client for the Neon API
- 20Redis: What's new in two - June 2026 edition
- 21DB-Engines: DB-Engines Ranking - July 2026
Contenido relacionado
- Inicia sesión para comentar.
