www.bortolotto.eu

Newsfeeds
Planet MySQL
Planet MySQL - https://planet.mysql.com

  • What’s New in MySQL NDB Cluster 9.x – Better Visibility and Control in MySQL NDB Cluster
    MySQL NDB Cluster 9.x continues to focus on the qualities that matter most in production: clear operational insight, predictable behaviour under failure, efficient application access, and faster recovery. This release series adds practical observability across the cluster, strengthens several exceptional paths, and expands the control available to users. Better visibility into cluster operation Diagnosing a […]

  • Benchmarking vector indexes in MySQL with vector-dev-bench
    PostgreSQL has a rapidly evolving vector ecosystem. MySQL is earlier on that road, but the community is hard at work catching up. MariaDB ships its own HNSW index, Google engineers have shared a ScaNN-based vector index on MySQL's own vector index proposal, Percona is building an HNSW index inside InnoDB, and VillageSQL is building vector search as an extension with vsql-vector. We want vector search on MySQL to be something that teams can choose with confidence (and not have to switch to PostgreSQL to get). Getting there takes more than one good implementation. The teams building these indexes need to measure them the same way, check each other's numbers, and fix what the numbers show. Working with Percona, we published vector-dev-bench. It runs on a laptop, it drives VillageSQL, MariaDB, PostgreSQL with pgvector, and MySQL built from Google's ScaNN pull request, and it gives an answer in minutes. Doing things in the open A benchmark number is only as good as the method behind it. A public method lets anyone rerun numbers, read the exact SQL each engine received, and tell us where the method may be unfair. It also makes collaboration practical. When another team can run the same harness against their own build, we can compare results without a bunch of upfront coordination. With vector-dev-bench, an engine is one entry in a Python dictionary plus a start script, so adding a new one is a small change. We've seen this work already. Percona's vector-bench is a full comparison framework, and we added VillageSQL to our copy of it. Along the way, we noticed that pgvector loaded its rows with COPY while the MySQL engines used INSERT, so the build times were measuring two different kinds of statements. We switched pgvector's incremental build to batched INSERTs so that every engine loads rows the same way. vector-bench adopted the change, and its code credits our commit. That is the kind of exchange we want more of. Two tools for two jobs vector-bench and vector-dev-bench answer different questions, and we use both. vector-bench is built to produce a comparison that you can publish. It runs each engine in Docker, built from pinned sources where it compiles them, runs real datasets such as SIFT, GloVe, and GIST, and measures recall against throughput, build cost, concurrency from 1 to 32 clients, filtered search, and recall after deletes and reinserts. It runs every engine twice, once with identical resources and once with each vendor's recommended settings, and it records the hardware and versions with every result. Its main profile takes about two days, which is the right cost for a number that other people will cite. vector-dev-bench is built for the quick, iterative loop in which you change the index, rebuild it, and want to know whether recall moved. It runs against engines you've already built, does not use containers, and uses synthetic data by default. It builds a 20,000-vector index in about 7 seconds. Its README is plain about the trade-off: the numbers are for relative comparisons, and a published comparison belongs in a framework like vector-bench. vector-dev-bench Measurement vector-dev-bench is three command-line tools over one shared module: Tool What it measures recall_bench.py It measures recall@k and queries per second across a sweep of ef_search values. It exits with an error when recall falls below a threshold (0.95 by default), so a script can use it as a pass/fail check. build_bench.py It measures index build time. --build-threads N builds the index from N client connections at once. rw_bench.py It measures reads during writes. Reader threads run nearest-neighbor queries while writer threads insert into the same index, and the tool reports read throughput second by second along with p50, p95, and p99 latency. Recall is the measure that matters here, because an approximate nearest-neighbor index returns approximately the right answer by design. A test that compares exact output, the way MySQL's own test framework does, fails on a correct index. vector-dev-bench computes the true nearest neighbors itself with NumPy and reports what fraction of them each engine returned. You can also pass --dataset to use a standard ann-benchmarks dataset with its published ground truth. The engines are profiles: Profile Engine vsql_vector VillageSQL with vsql-vector (SVECTOR column, HNSW index) mariadb MariaDB 11.7 or later (MHNSW) pgvector PostgreSQL 15 or later with pgvector google MySQL 9.7.1 built from Google's vector search commit (ScaNN index), which its authors describe as an experimental proof of concept varchar_ctrl A plain VARCHAR column, as a control that separates a server problem from a harness problem VillageSQL, MariaDB, and the Google build all speak the MySQL protocol, and the harness drives all three through the same PyMySQL connection code. The client cost is the same for each engine, but it isn't zero. A gap between two of these engines holds for the machine that measured it, and it can change on different hardware, so rerun it on the hardware you care about before you trust it. pgvector takes a different path. The harness sends each batch of pgvector inserts or queries through the psql command-line client, so the timed window also includes starting psql and opening its connection. The parallel options (--readers and --build-threads) fall back to one serial client, and rw_bench.py does not run against pgvector. A VillageSQL-versus-pgvector number from vector-dev-bench measures the two clients as well as the two engines. Treat it as a hint about where to look, and don't quote it as a verdict on either engine. What a run looks like We ran a recall sweep against VillageSQL 0.0.7 with the vsql-vector-pk build of the extension (whose HNSW index stores each row's primary key), on 20,000 random 32-dimension vectors. The tool builds the index once and then queries it at four ef_search values. The README and RUNBOOK cover building each engine and running the tools. Here is the output from an Apple M5 laptop with 32 GB of memory: build_time_s=7.03 (index built once; sweeping ef_search) ef_search recall@10 qps 50 0.7870 8829.3 100 0.9035 5903.0 200 0.9645 3526.0 400 0.9875 2044.4 This is the curve every HNSW index trades along. A wider search finds more of the true neighbors and answers fewer queries per second. The shape is also a check on the run itself: recall that stays at exactly 1.0 when ef_search drops usually means the optimizer chose a full table scan and the index wasn't used. MariaDB and PostgreSQL run the same sweep through their own profiles, and run_three_way.sh runs all three engines one after another so that only one server is busy at a time. Reads while the index is changing Benchmarks such as ann-benchmarks build the index once and then query a corpus that never changes. Production tables change all the time. rw_bench.py covers that case: it runs readers alone, adds writers for a window in the middle, and then runs readers alone again. This run used 4 readers and 4 writers against the same 20,000-vector index: total reads=47700 writes=2000 rows write_rate=432 rows/s over 4.6s read-only mean=4564 qps read+write mean=2738 qps impact=40% drop read latency (us) p50 p95 p99 max n read-only 797 1399 1805 87018 32038 read+write 1440 1803 1908 8991 10988 The per-second table in the full output shows reads dropping when the writers start at second 4 and recovering once they stop at second 8. For an index that lives inside a transactional engine, this is one of the numbers we care about most, because it shows what a busy table costs the queries that read it. When to use it, and when not to Use vector-dev-bench when you're changing an index and want to know within minutes whether recall, build time, or read throughput moved. Use it as a recall check in a script, since recall_bench.py exits with an error below its threshold. Use it to try an idea against MariaDB or pgvector on the same machine (for pgvector, recall and build time only) before you invest in a full run. Use a full framework such as vector-bench when the number is going to leave the room. That includes anything published, anything that compares absolute latency, and anything that depends on filtered search or recall after deletes. Latency under concurrency counts as absolute latency. A comparison with pgvector needs the full framework most of all, because pgvector is the engine whose client differs. Every number from vector-dev-bench passes through a client, so absolute latency includes the client and the round trip. Synthetic vectors give a trustworthy relative signal on the machine that ran them, but they don't predict recall on real embeddings. Add your engine The repository is Apache-2.0 licensed, and an AGENTS.md file walks a coding agent through running it. If you're building a vector index for MySQL, or for anything that speaks the MySQL or PostgreSQL protocol, add a profile and a start script and send a pull request. If you think our method is unfair to your engine, open an issue and tell us why. Getting vector search on MySQL to the point where teams can pick it with confidence is work for everyone in the MySQL community, and it starts with numbers we can all reproduce. You can get VillageSQL from the website, read how custom indexes work in the custom indexes documentation, and see our Percona Live demo in Vector search in MySQL: an early look at HNSW and custom indexes in VillageSQL.

  • Village News: MySQL News + Events (21 October 2026)
    Welcome back to Village News, our curated roundup of MySQL and database news. This issue covers two weeks, with MySQL 26.10 landing at the end of them. If you want to get these updates, just subscribe to the blog. Enjoy! MySQL News Note: Aggregated MySQL news can be found at Planet for MySQL Community and Planet MySQL (Oracle curated) MySQL 26.10 Is Here: New Capabilities for Developers and DBAs Oracle MySQL Blog TL;DR - MySQL 26.10 brings MySQL REST Service into the server as a component, so you no longer need MySQL Router to serve its HTTPS endpoints. Four Attempts and One RESET MASTER — Migrating a Terabyte of Production MySQL to Kubernetes (MOCO) Eugene Dimov, OurSQL Foundation Blog TL;DR - Ivinco rolled back three cutovers to MOCO, caused by a hardcoded VIP and Ceph write latency. After the move, a passwordless root account from the donor made the operator run RESET MASTER and wipe a replica's GTID history. MySQL vs PostgreSQL Internals (Part 3) – Row Locking Zhao Song TL;DR - Traces one SELECT … ORDER BY … FOR UPDATE through both engines. InnoDB locks rows as it scans and keeps the locks in memory. Postgres sorts a snapshot first, then locks and rechecks each tuple, recording the lock in the tuple header. Taming MySQL 8.4 Background Histogram Lock Wait Timeouts on Amazon RDS Umesh Shastry, MySQL :: under_the_hood TL;DR - RDS's monitoring agent holds a near-constant write lock on mysql.rds_heartbeat2, so 8.4's background histogram collection keeps timing out on it. The fix is to drop the histograms on that one table, not to change global settings. How fast is vector search inside MySQL? Alkin Tezuysal, AskDBA TL;DR - Benchmarks the MyVector HNSW plugin on three MySQL versions against MariaDB's native vector type. lefred's reply argues that MariaDB comes out ahead once you compare at matching recall. Announcing VillageSQL Server 0.0.7 VillageSQL Blog TL;DR - Builds now track MySQL 8.4.11, 9.7.2 and Percona Server 8.4.11-11. Extensions can now define custom indexes, including nearest-neighbor search, which lays the groundwork for vector search. “MySQL Is Still the Backbone”: Zongzhi Chen on Hot Rows, PolarDB, and the Agent Era OurSQL Foundation Blog TL;DR - An interview with a longtime MySQL contributor and early PolarDB engineer about why China runs on MySQL, what Singles Day does to hot rows, and where MySQL goes next. MySQL Online DDL "Duplicate Key" Optimization Libing Song TL;DR - Since 5.6, an online DDL can fail with a false Duplicate Entry error when concurrent DML fails on a unique key and leaves entries in the row log. This explains the cause and the fix shipped in AliSQL. InnoDB for the fast. DuckDB for the heavy. Same connection for both. Daniel Guzmán Burgos, dbtrail Blog TL;DR - dbtrail (Apache 2.0) reads the binlog into Parquet copies and routes each SELECT to InnoDB or DuckDB. 13 of 14 reports ran about 10x faster, while point lookups got slower. A companion post uses it for row-level recovery. How a Routine Linux fstrim Job Took Down MySQL: An InnoDB Crash Analysis Vinoth Kanna, Mydbops Blog TL;DR - A weekly fstrim sent about 5.2 TiB of discards to thick-provisioned disks and stalled I/O until InnoDB's 600-second semaphore watchdog killed mysqld. The fix is to disable fstrim.timer on such storage. MySQL Workbench 26.7 Dave Stokes, Dave's MySQL Stuff TL;DR - The new Workbench is a rewrite, not an update of the version retired in January. It lacks relationship maps and reverse engineering, and servers 8.0 and older are no longer supported. PGO or not PGO this is the dilemma. Step 1 Marco Tusa, Percona Blog TL;DR - A three-part look at profile-guided builds of MySQL 9.7.2. Steps 2 and 3 show why a build trained only on sysbench loses at high concurrency and recommend mixing MTR runs with moderate-concurrency training. Database News Neki update: $50 Metal, read-only replicas, Azure, and more Nick Van Wiggeren, PlanetScale Blog TL;DR - A month into preview, PlanetScale's sharded Postgres has added read-only replicas, Metal instances from $50/month, Azure regions, and Terraform and CLI controls. Make pg_stat_monitor stable again! Percona Community Blog TL;DR - pg_stat_monitor 2.4.0 fixes memory leaks that could end in an OOM kill, along with buffer overflows, a use-after-free, a lock-ordering bug and incorrect statistics. CedarDB Cloud Is Now Generally Available CedarDB Blog TL;DR - CedarDB, a Postgres-compatible database for both transactional and analytical workloads, is now available as a fully managed service. What gets TOASTed in Postgres Ahmed Darwich, PlanetScale Blog TL;DR - Postgres 19 makes LZ4 the default TOAST compression. LZ4 is usually the right choice, but pglz still compresses repetitive JSON smaller and reads large-value previews faster. In MariaDB 13.0, new-style optimizer hints go beyond MySQL’s Sergei Petrunia TL;DR - MariaDB 13.0 is stable, and its optimizer hints now go beyond MySQL's syntax, starting with path-based query-block addressing in QB_NAME. Load terabytes of data in minutes into Lakebase Postgres Databricks Blog TL;DR - Spark builds valid Postgres heap and index pages in parallel and writes them to storage, then the primary publishes them with one compact WAL record. Databricks reports loading 1 TB in under 5 minutes. Upcoming Database Events PGConf.EU October 20–23, 2026 (PostgreSQL Europe) Valencia, Spain MySQL Public Discussion #6 October 22, 2026, 17:00–18:00 UTC Online Oracle AI World October 25–28, 2026 Las Vegas, NV PG Down Under 2026 October 30, 2026 Surry Hills Sydney, Australia MySQL Contributor Summit November 4-5, 2026 Virtual KubeCon + CloudNativeCon North America (VillageSQL is a sponsor) November 9-12, 2026 Salt Lake City, Utah PASS Data Community Summit November 9-11, 2026 Hyatt Regency Seattle Seattle, WA DuckDB × MySQL Day November 17, 2026 Online PGConf.Asia 2026 November 17-18, 2026 Hong Kong PGConf.PL 2026 November 24, 2026 ARCHE Dwór Uphagena Gdańsk, Poland AWS re:Invent 2026 November 30 – December 4, 2026 Las Vegas, NV Open Source Summit Japan December 7-9, 2026 Tokyo, Japan CIDR 2027 January 24-27, 2027 Mövenpick Hotel Amsterdam City Centre Amsterdam, The Netherlands MySQL Belgian Days 2027 January 28-29, 2027 ICAB Incubator Brussels, Belgium FOSDEM PGDay 2027 January 28-29, 2027 Brussels Marriott Hotel Grand Place Brussels, Belgium FOSDEM 2027 January 30-31, 2027 ULB Solbosch Campus Brussels, Belgium CERN PGDay 2027 February 12, 2027 CERN Council Chamber Geneva, Switzerland PGConf India 2027 March 2-5, 2027 Sheraton Grand Hotel at Brigade Gateway Bengaluru, India FOSSASIA PGDay 2027 March 9, 2027 Bangkok, Thailand KubeCon + CloudNativeCon Europe 2027 March 15-18, 2027 Barcelona, Spain Nordic PGDay 2027 March 16, 2027 Courtyard Kungsholmen Stockholm, Sweden SCaLE 24x April 1-4, 2027 Pasadena Convention Center Pasadena, CA PgDay Boston 2027 April 10, 2027 Tufts University Joyce Cummings Center Boston, MA PGConf.dev 2027 May 11-14, 2027 Plaza Centre-Ville Montréal, QC, Canada

  • MySQL October 2026 GA Releases Now Available
    The October 2026 MySQL releases are now available, including: MySQL 26.10 brings additional capabilities to Community Edition, new options for building REST applications, and improvements to database operations and developer tools. MySQL 9.7.4 and MySQL 8.4.13 continue maintenance updates for the supported LTS release lines. October MySQL Server releases MySQL 26.10 Innovation delivers new functionality […]

  • Introducing the MySQL REST Service Component: Now Generally Available
    With MySQL 26.10, we’re announcing the general availability of the MySQL REST Service (MRS) Component, an installable component that runs MRS directly inside MySQL Server. MRS: the MySQL REST Service Many modern applications, well, not just applications, but also tools, CLIs, CI pipelines, and automation, use HTTP and JSON to communicate with other systems. For […]