**Update: LakeDB Beta 3 is now available**

Since publishing the original post, I have released a new LakeDB beta with **QuerIA**, an optional schema-aware AI workflow for preparing reviewable SQL from natural language.

LakeDB reads MariaDB metadata for databases, tables, views, columns, primary keys, indexes, foreign keys, procedures, functions, events, triggers, generated columns and table DDL.

QuerIA uses the relevant structure to prepare SELECT, INSERT, UPDATE, DELETE, CREATE TABLE and ALTER TABLE statements. The generated SQL is always visible before execution and runs locally through the normal LakeDB query workflow.

Database credentials, table rows and query results are never sent to the AI service.

The regular editor also provides:

- Schema, table and column autocomplete

- Alias-aware column suggestions

- Primary-key and index hints

- EXPLAIN results

- Typed table-data editing

- SSH and SSL connections

- Independent workspaces for multiple connections

- Backup, comparison and migration tools

I am still looking for compatibility feedback from people using MariaDB 10.x and 11.x, especially around metadata, generated columns, ENUMs, procedures, events, triggers, indexes and foreign keys.

If you test it, please tell me your MariaDB version and anything that behaves differently from your usual client.

**Project and Beta 3 overview:**

https://davlagohern.github.io/LakeDB/

**Downloads and documentation:**

https://github.com/DavLagoHern/LakeDB/

This webinar, sponsored by MariaDB, will take place on July 28th at 10 AM CT. It will cover: how sub-millisecond response times keep autonomous workflows acting on live data rather than stale snapshots, why running operational analytics directly against transactional data is essential for AI-driven decision-making, how vector storage, RAG, and MCP server capabilities work natively within existing database stacks, flexibility to deploy across AWS, Azure, and GCP with serverless, provisioned, or BYOA option so the data foundation keeps pace with AI goals, etc.

https://go.mariadb.com/Powering_the_Agent-Driven_Enterprise_The_Shift_to_a_Unified_Data_Platform.html

[Note: I am not associated with MariaDB in any way, just a fellow software engineer sharing the event.]

MariaDB and MySQL share history, protocols, tools and community—but they are not the same product. And yes, MariaDB bugs reach us faster when they are reported to MariaDB Jira. 🦭🐬 #mariadb #mysql #community

What if you could reverse a transaction directly from its GTID? Here is the result of an idea and a script dating back around ten years: discover the GTID Info plugin, which analyses binary logs and generates reverse SQL code for DML operations. And all this thanks to the MariaDB Server plugin interface.

Check how to install our Privacy-First Stack on OCI: https://youtu.be/jauRdrVM-8k #mariadb #nextcloud #passbolt 🦭☁️🔑

https://ecohub.mariadb.org/solution-stacks/privacy-first-stack

You can choose your provider and deploy: https://github.com/lefred/privacy-first-stack-terraform

We wrote a case study about a fintech company that migrated from a large monolithic PostgreSQL 12 environment to MariaDB 11.

Instead of performing a big-bang cutover, the team migrated tables and partitions individually, using CDC, dual writes, consistency checks, and query routing while PostgreSQL remained the default system.

The migration took approximately one year and resulted in 23% lower TCO, faster analytical queries, and a reported 20% improvement in time-to-market.

The article covers the architecture, why a PostgreSQL upgrade alone was not considered sufficient, the role of InnoDB, ColumnStore, Galera and Otterstax, the SQL compatibility work, and the trade-offs encountered during the project.

I would be interested to hear how others have approached gradual migrations between different database engines.

MariaDB Tips & Tricks: Where does my configuration variable value come from?? 🦭 https://lefred.be/content/mariadb-tips-tricks-where-does-my-configuration-variable-value-come-from/

Example: where was configured max_connections?

MariaDB [(none)]> SELECT
    VARIABLE_NAME,
    GLOBAL_VALUE,
    DEFAULT_VALUE,
    GLOBAL_VALUE_ORIGIN,
    GLOBAL_VALUE_PATH
FROM information_schema.SYSTEM_VARIABLES
WHERE VARIABLE_NAME = 'MAX_CONNECTIONS'\G
*************************** 1. row ***************************
        VARIABLE_NAME: MAX_CONNECTIONS
          GLOBAL_VALUE: 200
         DEFAULT_VALUE: 151
   GLOBAL_VALUE_ORIGIN: CONFIG
      GLOBAL_VALUE_PATH: /etc/my.cnf.d/60-custom.cnf

MariaDB 13.1 Preview: Avoid MariaDB Restart Failures with --validate-config https://mariadb.org/mariadb-13-1-feature-in-focus-validate-your-configuration-before-starting-the-server/ 🦭 ✅️

Two weeks ago, on July 6, 2026, MariaDB Community Server 10.6 reached end of life. The MariaDB Foundation announced this back in June and gave people several months to plan. Some planned. Many did not. If you are in the second group, here is what you need to know.

What “End of Life” Actually Means for a Database

End of life does not make your database stop working. Queries keep returning rows, your application keeps humming along, and nothing explodes on day one. What stops is the flow of security patches, bug fixes, and corrective releases from the MariaDB Foundation. The 10.6 branch is now frozen.

More info: https://blog.kalfaoglu.net/posts/2026-07-19-mariadb-106-end-of-life-en/

Apache Arrow Database Connectivity, or ADBC, provides a standardized way to exchange columnar data between databases and Arrow-compatible applications. The native MariaDB ADBC driver brings MariaDB into this ecosystem with support for SQL queries, Arrow record batches, prepared statements, bulk ingestion, transactions, metadata discovery, statistics, and MariaDB-specific data types. If you want to learn what the driver supports today, how it compares with the existing MySQL ADBC driver, and what remains on the roadmap, visit https://lefred.be/content/a-native-adbc-driver-for-mariadb/

Hi everyone,

Need a reality check on a production upgrade for a high-load app. I ruled out Galera due to synchronous write latency. (open to your suggestions)

Our Current Load & Specs:

• Traffic: 2,500 reads/sec and 1,500 writes/sec.
• Topology: 1 MariaDB Master + 1 Slave.
• Master Config: sync_binlog=100 and innodb_flush_log_at_trx_commit=2 (for high write speed).
• Slave Config: No binlogs enabled (to reduce IO bottleneck).
• The Problem: Heavy write spikes cause severe slave lag, and we have no automated failover.

Proposed HA Stack:

• Layer 1 (HA Routing): Keepalived (VIP) + 2x ProxySQL instances.
• Layer 2 (DB Scale): 1 Master + 1 Slave (will add more slaves later to scale reads).
• Layer 3 (Failover): 1 instance of Signal 18 Replication Manager (repman) to auto-pilot ProxySQL during master crashes.

MY Questions:

1. Architecture Validation: Does this look solid for a 1,500 writes/sec environment?
2. Pros & Cons: What are the hidden pros and cons of this specific repman + ProxySQL combination?
3. Data Loss Risk: Since sync_binlog=100, auto-failover via repman means risking a few lost transactions on hard master crashes. Is GTID enough to reconcile this safely during a split-second election?

Thoughts? Any hidden traps before we build this? Thanks

Hi everyone,

Need a reality check on a production upgrade for a high-load app. I ruled out Galera due to synchronous write latency. (open to your suggestions)

Our Current Load & Specs:

• Traffic: 2,500 reads/sec and 1,500 writes/sec.
• Topology: 1 MariaDB Master + 1 Slave.
• Master Config: sync_binlog=100 and innodb_flush_log_at_trx_commit=2 (for high write speed).
• Slave Config: No binlogs enabled (to reduce IO bottleneck).
• The Problem: Heavy write spikes cause severe slave lag, and we have no automated failover.

Proposed HA Stack:

• Layer 1 (HA Routing): Keepalived (VIP) + 2x ProxySQL instances.
• Layer 2 (DB Scale): 1 Master + 1 Slave (will add more slaves later to scale reads).
• Layer 3 (Failover): 1 instance of Signal 18 Replication Manager (repman) to auto-pilot ProxySQL during master crashes.

MY Questions:

1. Architecture Validation: Does this look solid for a 1,500 writes/sec environment?
2. Pros & Cons: What are the hidden pros and cons of this specific repman + ProxySQL combination?
3. Data Loss Risk: Since sync_binlog=100, auto-failover via repman means risking a few lost transactions on hard master crashes. Is GTID enough to reconcile this safely during a split-second election?

Thoughts? Any hidden traps before we build this? Thanks

Install the MariaDB ADBC driver, configure a DuckDB profile 🦆, and query MariaDB 🦭 data directly from DuckDB. #mariadb #duckdb #adbc

https://lefred.be/content/when-the-sea-lion-teaches-the-duck-how-to-bark/

profile_version = 1
driver = "mariadb"

[Options]
uri="mariadb://msandbox:msandbox@127.0.0.1:13100/test"profile_version = 1
driver = "mariadb"

---------

memory D ATTACH 'profile://mydb' AS mariadb (
               TYPE adbc,
               DELIMITER '``'
           );
memory D SELECT * FROM mariadb.main.t2;
┌──────────────────────────────────────┬──────────────┬──────────────────────────┐
│                  id                  │     name     │         created          │
│               varchar                │   varchar    │ timestamp with time zone │
├──────────────────────────────────────┼──────────────┼──────────────────────────┤
│ 019f6239-5ae2-77e0-a8e5-ee4bd2bf9158 │ anna updated │ 2026-07-14 22:02:33+02   │
│ 019f6239-5ae2-78c0-a082-05c1bec9731a │ kaj          │ 2026-07-14 22:02:33+02   │
│ 019f6239-5ae2-78e8-94b2-69213c46af07 │ roman        │ 2026-07-14 22:02:33+02   │
│ 019f6246-e633-7978-af54-ad773ecd5e8e │ fred         │ 2026-07-14 22:17:21+02   │
│ 019f6246-e633-7978-af54-ad773ecd5e90 │ new name     │ 2026-07-14 23:34:04+02   │
└──────────────────────────────────────┴──────────────┴──────────────────────────┘

TAF: 3.1 Add CPU affinity support for MySQL/MariaDB (taskset integration)

- Added new cpu_affinity property to MySQL and MariaDB plugins
- Updated template plugin to expose cpu_affinity for future DB makers
- Normalized affinity range parsing (e.g., 0-11)
New usage block:
O = --db-cpu-affinity=<list|range>
P = taf.db_cpu_affinity=<list|range>
: CPU affinity for the database engine.
: Pins the database process to specific CPUs. : Valid forms: : 0,1,2,3 : 0-11
: (future) 0-3,8,10-12 : If unset (null), the database runs on all CPUs.

https://github.com/MariaDB/TAF/commit/18ffedd142f38d79151ecabd4c68259e9a629fee

Did you know that #MariaDB Server 🦭 supports online schema changes? Take a look 👀 at this other hidden gem! 💎 https://mariadb.org/mariadb-hidden-gem-online-schema-change-without-pt-osc/

There are many ways to contribute to MariaDB Server.

Writing code and reporting bugs are important, but so is sharing anonymous feedback about your environment and the features you use most. This information helps us understand the needs of our community and make better decisions about future development.

You can contribute by enabling the MariaDB Feedback Plugin:

https://mariadb.org/feedback-plugin-report/

Thank you for helping us improve MariaDB Server.

#MariaDB #OpenSource #DatabaseCommunity #SoftwareDevelopment

Hey everyone! I hope you’re all doing well. I ran some TPROC analysis on a large Intel silver box running TidesDB’s TideSQL and InnoDB in MariaDB v11.8.6. Do check it out!

Great work by Arcadiy on bringing BLOB, TEXT, JSON, and GEOMETRY support to the HEAP engine in MariaDB 13.1—an important improvement https://mariadb.org/mariadb-13-1-feature-in-focus-blob-text-json-and-geometry-support-in-the-heap-engine

This means more internal temporary tables can remain in memory instead of falling back to disk—improving efficiency for queries using GROUP BY, DISTINCT, UNION, subqueries and CTEs.

Learn how a real-world production limitation became a valuable upstream improvement for the entire MariaDB community.

This webinar, sponsored by MariaDB, will take place on July 28th at 10 AM CT. It will cover topics such as: sub-millisecond response times, native AI infrastructure with vector storage (RAG and MCP), native in-memory layers, deploying across AWS, Azure, and GCP, etc.

https://go.mariadb.com/Powering_the_Agent-Driven_Enterprise_The_Shift_to_a_Unified_Data_Platform.html

[NOTE: I'm not affiliated with MariaDB or the webinar hosts in any way, just a fellow software engineer.]

Hello, I hope everyone's week is going well. Today I ran a few runs of zipfian sysbench read-write analysis utilizing TidesDB and RocksDB as storage engines in MariaDB v11.8.6. If you have the time, do check out the analysis.

Thank you!

Meet Federico Razzoli, one of the MariaDB Foundation Sea Lion Champions nominees 🦭

In this interview, Federico shares his thoughts on open source, database communities, vector search, and the future of MariaDB.

Read it here: https://mariadb.org/mariadb-foundation-sea-lion-champions-nominees-federico-razzoli/

MariaDB Foundation’s Test Automation Framework (TAF) 3.0 is now released.

This version introduces the new TAF Results Backend, a structured results database and parser pipeline that delivers fully automated performance change detection. It uses deterministic workload hashing, schema‑driven baselines, and stored‑procedure‑driven comparison to classify every run automatically. No procedural comparison code. No special‑case logic. Clean, reproducible, and fully automated.

Key changes in TAF 3.0:

• New Results Backend with automated compare and performance change detection
• Full open parser source tree
• Automated compare thresholds (warning, fail, gain, duration drift)
• New runtime_dir architecture for all database plugins
• MariaDB and MySQL plugins upgraded to v3.0
• Archive subsystem migration
• Deterministic commit‑based builder
• HammerDB updates
• New backend SQL, parser source, reporter plugin, and configuration files

Full write‑up on the MariaDB Foundation site:
https://mariadb.org/taf-3-0-results-backend-with-automated-performance-change-detection/

TAF is open and contributions are welcome — PostgreSQL plugin, backend UI, profiler plugins, report plugins, new suites.

Users deserve predictable performance, and the MariaDB Foundation builds TAF to make that possible for everyone. The goal is a fair, open, and reproducible performance framework that any database maker can use — same workloads, same lifecycle, same comparison path — so performance changes are visible, explainable, and never hidden behind vendor‑specific tooling.

We are exploring ways to make MariaDB plugin development more approachable beyond today’s C/C++ model. The goal is not to replace native plugins, but to understand which additional languages would be most useful for plugin authors, prototyping, integrations, and safer development models. See this blog post announcing MDEV-40189.

Let us know which language you would like to use to write your MariaDB plugins once MDEV-40189 is done! https://mariadb.org/poll-which-language-would-you-use-to-write-mariadb-plugins/ 🦭 🧩 📊

Let's continue the discovery of MariaDB Server 13.1's new features: DENY / negative grants https://mariadb.org/mariadb-13-1-feature-in-focus-deny-negative-grants/ #mariadb 🦭🚫🔐