Home News feed Planet MySQL
Newsfeeds
Planet MySQL
Planet MySQL - https://planet.mysql.com

  • Making Sense of MySQL Telemetry Metrics
    In the first post in this series, we configured MySQL Telemetry to export OpenTelemetry metrics to Prometheus. Once the metrics arrive, the more important question is how a DBA should read them. This post is not a catalogue of every metric or meter. Its purpose is to build a practical way of thinking: start with […]

  • Why MySQL Bug Fixes Can Differ Across LTS Releases
    At a recent discussion with MySQL ACEs and Rockstars, we were asked a fair question: If a bug is fixed in one supported MySQL LTS series, why isn’t it always fixed in another? A quick refresher: LTS means Long-Term Support. Within an LTS series, MySQL aims to keep the feature set and data format stable […]

  • DBTrail: Analytical Reports on Your MySQL Data, Without Running Them on MySQL – Part 1
    MySQL is very good at serving application workloads, but things get more complicated when somebody decides to run a large report on the same server. A scan can push hot pages out of the buffer pool. A long-running read can hold back purge. A GROUP BY over millions of rows can start writing temporary tables to disk. The traditional answer is a reporting replica. But that means running another MySQL server, and at the end of the day it is still a row-oriented database. Another option is moving the data into an analytical database. That can work very well, but now you have a data pipeline to build, operate, monitor, and eventually debug. We have been looking at what MySQL users can do with DuckDB, and DBTrail is an interesting approach. DBTrail is open source under Apache 2.0. It is being built by Daniel Guzman-Burgos, who previously worked at Percona as a MySQL Technical Lead. The basic idea is simple. DBTrail connects to MySQL similarly to a replica. It makes an initial copy of the tables using mydumper and stores the data as Parquet files, either locally or in S3. After that, it reads the MySQL binary log and periodically applies changes to the copy. You query the resulting data with DuckDB. Nothing is installed inside MySQL, there is no MySQL plugin, agent, or trigger. The setup would look like this: Let’s do some performance testing. The setup We used three AWS machines in the same subnet in us-west-2a. Role Machine Software Source r7i.4xlarge Percona Server for MySQL 8.4.11-11 DBTrail and DuckDB r7i.4xlarge DBTrail 0.99.0, DuckDB 1.5.6 Load generator c7i.2xlarge sysbench 1.0.20, sysbench-tpcc Machines in more detail Source and DBTrail machines Load machine CPU Intel Xeon Platinum 8488C, 8 cores, 16 threads Same CPU, 4 cores, 8 threads Memory 128 GB, 123.8 GB usable 16 GB Disk EBS gp3, 400 GB, 16,000 IOPS, 1,000 MB/s provisioned Not used by the test Filesystem ext4, relatime,discard,commit=30 I/O scheduler none, 128 KB read-ahead OS Ubuntu 24.04.5, kernel 7.0.0-1013-aws Same Kernel settings swappiness 60, dirty ratio 20/10, THP madvise Same Docker 29.1.3 The MySQL source Percona Server runs in Docker using host networking. We used full durability and a buffer pool large enough to keep the whole data set in memory:<code>innodb_buffer_pool_size = 96G innodb_redo_log_capacity = 32G innodb_flush_log_at_trx_commit = 1 sync_binlog = 1 innodb_flush_method = O_DIRECT innodb_io_capacity = 8000 innodb_io_capacity_max = 16000 binlog_format = ROW binlog_row_image = FULL gtid_mode = ON</code>The workload is sysbench-tpcc with 200 warehouses, which produces 102 million rows and about 19 GB of data when the run started. For the initial workload we held the workload at 300 transactions per second. One TPC-C transaction in this test is roughly 28 SQL statements, so that means about: 8,500 QPS 5,200 row changes per second It is important to put that load into context—on the same server flat out with 64 threads and nothing else attached, it reached 4,049 transactions per second, or about 115,000 QPS. So the 300 TPS test uses only about 7% of the available capacity, and we chose a relatively light load intentionally. We wanted to see what analytical queries cost even when the source has plenty of headroom. DBTrail DBTrail installs with one command that starts its Docker Compose stack:<code>curl -fsSL https://raw.githubusercontent.com/dbtrail/dbtrail/v0.99.0/install.sh \ | DBTRAIL_REF=v0.99.0 sh</code>The stack contains two containers: DBTrail itself and a MySQL 8.4.9 instance DBTrail uses as an index of row changes. This internal MySQL needs attention, as the default installation leaves its buffer pool at MySQL’s 128 MB default. For this workload, that is nowhere near enough. For the main tests we configured it like this:<code>innodb_buffer_pool_size = 48G innodb_redo_log_capacity = 16G innodb_log_buffer_size = 256M innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT innodb_io_capacity = 8000 innodb_io_capacity_max = 16000 innodb_page_cleaners = 16 innodb_flush_neighbors = 0 skip-log-bin</code>DuckDB ran on the same machine with its defaults: 16 threads and a 99 GB memory limit. Does DBTrail slow MySQL down? Short answer: at this workload, almost not at all. The load ran continuously. Each row below represents one phase of the same test. Phase TPS QPS Median 95th percentile Worst second Nothing attached, 10 min 299.9 8,554 41.9 ms 46.6 ms DBTrail reading binlog, 10 min 300.5 8,535 41.9 ms 47.5 ms Initial copy of all tables, 4m 40s 298.1 8,460 41.1 ms 118.9 ms Copy updated every 5 min, 75 min 300.2 8,539 41.1 ms 46.6 ms There is one spike here that stands out. When the initial copy started, at approximately second 1,500 of the workload, the 95th percentile latency jumped to 119 ms and throughput dropped to 271 transactions for that second and it happened once. The initial copy takes a global read lock briefly when it starts, and the timing matches that operation, after that, DBTrail read 102 million rows in less than five minutes without any measurable slowdown in the application workload. CPU usage confirms the same story: the source normally sat around 18% CPU, but during the initial table copy it increased to about 35%. When we later ran the five analytical reports directly against MySQL, CPU was around 24%. There is also a noticeable increase in source writes around minute 12. That happened three minutes before DBTrail connected, so it was unrelated to DBTrail. The DBTrail machine itself writes roughly as much as the source because it keeps an index of every captured row change. Query times on the TPC-C data DBTrail creates a views.sql file containing a DuckDB view for each source table. From there you can query the data normally:<code>$ duckdb -init views.sql D SELECT i.i_id, i.i_name, sum(ol.ol_quantity) AS units, sum(ol.ol_amount) AS revenue FROM tpcc.order_line1 ol JOIN tpcc.item1 i ON i.i_id = ol.ol_i_id GROUP BY i.i_id, i.i_name ORDER BY revenue DESC LIMIT 10;</code>We ran the same five reports against MySQL and against DuckDB while the transactional workload continued running, during the workload the data had grown from 102 million to 113 million rows. MySQL had essentially everything cached in memory and the DBTrail copy was also in its normal operating state: a base Parquet file plus the accumulated change files that DuckDB needs to combine when executing the query. The results: Report MySQL DuckDB on DBTrail copy Revenue per warehouse 9.7 s 0.75 s Orders and revenue per district/month 46.5 s 2.8 s Ten best-selling items 5m 32s 1.7 s Customers by state and credit 3.6 s 0.18 s Warehouses low on stock 3.0 s 0.23 s Total 6m 35s 5.7 s This is where the difference becomes interesting: 6m 35s on MySQL and less than 6s on DuckDB. Running TPC-H: all 22 queries TPC-H is a more standard analytical workload; for this test, we loaded TPC-H at scale factor 10. The dataset contained: 86.6 million rows 18.2 GB of InnoDB data Normal indexes on join keys, order dates, and ship dates The initial DBTrail copy took 6 minutes 26 seconds and produced 2.8 GB of Parquet files. We ran the same SQL against both systems and compared results: MySQL DuckDB warm All 22 queries 5m 24s 10.3 s MySQL wins Q19 because an index can go directly to the relevant rows, Q17 is effectively a tie and for the rest, DuckDB is substantially faster. If you are interested in these performance numbers, stay tuned for Part 2, where we will look into how often DBTrail refreshes data to stay up to date. The post DBTrail: Analytical Reports on Your MySQL Data, Without Running Them on MySQL – Part 1 appeared first on Percona.

  • Village News: MySQL News + Events (6 October 2026)
    Welcome back to Village News, our curated roundup of MySQL and database news. 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) Thread Pool in Percona Server and MySQL (Part 1) Percona Blog TL;DR - MySQL 26.7.0 and 9.7.2 bring a thread pool to Community Server for the first time. TidesDB now available for MySQL v9, v26 Alex Gaetano Padula, TidesDB Blog TL;DR - TideSQL-MySQL 2.0.0 loads the TidesDB engine as a plugin into stock MySQL 9.7.0 and 26.7.0, so TidesDB tables can sit alongside InnoDB tables in the same server. For now it installs with a script from the repository. How easy is it to use the VillageSQL MCP extension? Ronald Bradford TL;DR - Ronald built and installed vsql-mcp on a throwaway server in about four minutes and answered a business question through a SELECT-only MCP user. His attempts to get past its guardrails were blocked. Database News Supabase is acquiring Turso Paul Copplestone, Supabase Blog TL;DR - Supabase is buying Turso, the team that rewrote SQLite in Rust, to build database infrastructure for AI agents. Turso founders Glauber Costa and Pekka Enberg join Supabase's leadership. Amazon Aurora's analytics is DuckDB: a reproducible side-by-side with pg_duckdb Franck Pachot TL;DR - Franck puts Aurora PostgreSQL's aurora_analytics and pg_duckdb side by side. The EXPLAIN plans match, down to DuckDB's internal compression operators and constants, which shows that Aurora's S3 Parquet/Iceberg analytics runs on embedded DuckDB. MariaDB Foundation Adds PostgreSQL to Its Engine‑Agnostic Testing Framework (TAF). Jonathan Miller, MariaDB Foundation TL;DR - TAF gains a PostgreSQL plugin and beta HammerDB TPROC-C/TPROC-H and Sysbench profiles, so MariaDB, MySQL and Postgres can be benchmarked under identical, reproducible conditions. Scale without limits: Multigres, OrioleDB, and dbarena Supabase Blog TL;DR - At Supabase Select, the company launched three things. Multigres (pooling and multi-node failover for Postgres) is in private alpha. The OrioleDB storage engine is in public beta. dbarena, an open benchmark site comparing managed Postgres providers, is live. When AI Finds the Bugs We Missed: A Very Busy Year for MariaDB Security Frédéric Descamps, MariaDB Foundation TL;DR - AI-assisted research drove 173 security reports over two quarters, which led to 27 published advisories and delayed some MariaDB releases. Update to the latest maintenance releases. Benchmark Analysis with HammerDB TPROC-C(TPC-C) on TideSQL v5.1.0, InnoDB in MariaDB v11.4.13 Alex Gaetano Padula, TidesDB Blog TL;DR - On a 3,000-warehouse TPROC-C run, TideSQL and InnoDB peaked at similar NOPM, but InnoDB had half the p99 latency. TideSQL held throughput at 128 VUs, where InnoDB dropped 34%. The author notes that one InnoDB setting was left untuned. Influence Is Not Ownership: Anna Widenius and Kaj Arnö on Governance, Open Source, and the Future of MariaDB Roberto V. Zicari, ODBMS Industry Watch TL;DR - The MariaDB Foundation's leaders explain its newly formalised governance. Authority comes from contribution rather than employer, and there is a defined path from contributor to committer, reviewer and maintainer. Designing Neki for performance Dirkjan Bussink, PlanetScale TL;DR - PlanetScale's sharded-Postgres router decodes lazily. Point lookups pass through as raw wire-protocol bytes, and only sort keys or row boundaries get decoded when a query needs them. Working with foreign key constraints in Aurora DSQL Rekha Reddy Anupati and Arnab Chowdhury, AWS Database Blog TL;DR - Aurora DSQL foreign keys are checked against the transaction snapshot, and conflicting concurrent key changes fail at commit with SQLSTATE 40001. Cascades count toward the 3,000-row transaction limit, and existing tables can use NOT VALID plus async validation. Upcoming Database Events High Performance Transaction Systems (HPTS) October 4-7, 2026 Asilomar Conference Grounds Pacific Grove, CA Open Source Summit Europe October 7-9, 2026 Prague, Czechia Community Over Code 2026 October 11-14, 2026 Hilton Glasgow Glasgow, UK TiDB SCaiLE 2026 October 15, 2026 Computer History Museum Mountain View, CA All Things Open 2026 October 19-20, 2026 Raleigh Convention Center Raleigh, NC PGConf.EU October 20–23, 2026 (PostgreSQL Europe) Valencia, Spain P99 CONF 2026 October 21-22, 2026 Online 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 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 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 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

  • Movie Finder: semantic search over 1M films, inside MySQL
    Type “a heist that goes wrong in a snowy town” and get back real films, with posters, in a few milliseconds. The vector search behind it runs inside MySQL, with no separate vector database. Movie Finder is the new demo app that ships with MyVector. It searches up to 1,035,695 TMDB movies by meaning, not keywords. One docker compose up gives you the whole thing: MySQL 9.7 with the MyVector component, a loader, and a small web app. Try it live: https://demo.myvector.online/ We built it to answer the questions people ask us most. Does vector search in MySQL hold up at a million rows? Can I mix it with ordinary WHERE filters? What happens when I insert a new row? The demo shows the answers on the page, with the SQL that ran under every result. Live: What you can do on the page Every feature on the page maps to a MyVector capability, and every result panel shows its SQL. Describe a movie in your own words and get the nearest films. Ask for “a boy wizard at a school of magic” and Harry Potter comes back first. Filter by genre, year, rating and language. These are plain SQL predicates combined with the vector search, and the page tells you which filtered-search path ran and why. Rank by similarity alone, or with a small boost for films many people have rated, so the famous match beats an obscure one at almost the same distance. Both are ordinary ORDER BY expressions. More like this: a film’s stored vector becomes the next query, in pure SQL. HNSW vs exact: run both side by side and compare speed and recall. Add a movie: a plain INSERT, searchable within about a second, with no index rebuild. (Not on live demo) Under the hood: live index details from myvector_index_status, a bar showing where each query’s time went, and a speed-vs-recall chart that sweeps ef_search from 10 to 640 against an exact scan. How it works The app embeds only your query text; every movie’s vector already sits in MySQL, so a search is one SQL round trip. The movie vectors come with the dataset, made by nomic-embed-text-v1.5 from each film’s title, tagline, and overview. The app uses the same model locally on the CPU, so there is no API key, and nothing leaves your machine. New rows need no rebuild. Adding a movie is a plain INSERT; MyVector’s binlog listener picks it up and adds it to the HNSW index, usually within a second. The SQL The whole index is declared in a column comment. This is the movies table’s vector column: embedding VARBINARY(3080) COMMENT 'MYVECTOR COLUMN type=HNSW,dim=768,size=...,M=16,ef=100,dist=Cosine,online=Y,idcol=id,threads=N' The loader inserts the rows, then builds the HNSW index with one call: CALL mysql.myvector_index_build('movies.movies.embedding', 'id'); A search turns the query vector into a nearest-first list of ids with myvector_ann_set(), then joins back to the table. JSON_TABLE keeps the order: SELECT m.title, myvector_distance(m.embedding, @q, 'Cosine') AS distance FROM (SELECT myvector_ann_set('movies.movies.embedding', 'id', @q, 'nn=10,ef_search=100') AS js) src, JSON_TABLE(src.js, '$[*]' COLUMNS (rank_no FOR ORDINALITY, id INT PATH '$')) nn JOIN movies.movies m ON m.id = nn.id ORDER BY nn.rank_no; “More like this” needs no embedding at all. It reads a film’s stored vector into the query variable: SELECT embedding INTO @q FROM movies.movies WHERE id = @movie_id; Filters pick one of two paths. The app counts each filter on its own index and takes the smallest count as an upper bound: 50,000 matches or fewer: it passes the matching keys as the fifth argument of myvector_ann_set, so HNSW searches only among them. More than that: it calls MYVECTOR_ANN_FILTERED, which takes the nearest candidates and keeps those that pass the filter. Run it yourself To run your own copy, from a clone of the repository: cd examples/movie-finder MOVIES=100k docker compose up # then open http://localhost:8080 The first start downloads the TMDB data, about 7 GB, once. MOVIES picks how many films to load, most-voted first: 10k, 100k (the default) or full. Measured on a 16-core Arm (Neoverse-N1) Linux host with MySQL 9.7.2: Step10k100kfull (1,035,695)Insert7 s41 s407 sBuild the HNSW index (16 threads)29 s33 s545 sHNSW search3–5 ms4–7 ms5–20 msExact search (scans every row)30 ms280 ms3 s warmRecall@10, HNSW vs exact100%100%100% At a million movies, HNSW answers in 5–20 ms where a full scan takes 3 seconds, with the same top 10. Recall is for the unfiltered test query; a broad genre filter (Drama) at full size gave 80% at ef_search 100, and the page lets you raise ef_search to trade time for recall. For the full profile, give Docker about 12 GB of memory and set MYSQL_BUFFER_POOL=6G. Running it on a remote server? The page and MySQL listen on localhost only. Forward the port instead of opening it: ssh -N -L 8080:127.0.0.1:8080 <server>. Version note: the demo uses features newer than the v1.26.9 images: filtered search, MYVECTOR_ANN_FILTERED, per-query ef_search, and online updates that survive a restart. Until the next release ships, the README shows how to build a local image from main. Data: the movie metadata and posters come from TMDB via a Hugging Face mirror. Your machine downloads it; it is not in the repository or any image. This is a non-commercial demo, not endorsed by TMDB. Try it and tell us Try the live demo first. To run your own, start with MOVIES=10k for a quick first look, then go to full to watch a million rows answer in milliseconds. The demo guide has screenshots and the other demos; the Movie Finder README has the full details. If a query surprises you, or you want a feature the page doesn’t show yet, open an issue on GitHub. A star helps other MySQL users find the project.

Banner
Copyright © 2026 studiolegalemenza.it. Tutti i diritti riservati.
Joomla! è un software libero rilasciato sotto licenza GNU/GPL.
  

Hosting powered by JoomlaHost.it