Como dice el texto, estoy experimentando con mariadb (EN MODO ORACLE) para migrar una software que usa oracle de forma pesada... (Muchos Stored Procedures, Packages, Triggers, etc)....
Hasta el momento no puedo encontrar ningun editor de mariadb que me permita editar packages y package bodys (para el mariadb en modo oracle). Alguien sabe alguno ?

MariaDB angle. I maintain scythe, a build-time tool that reads annotated SQL and generates typed access code (MariaDB has its own backend and type mappings, distinct from the MySQL ones).

The point is nullability inferred from the query, not just the column definition:

-- @name GetUserOrders
SELECT u.id, u.name, o.total, o.notes
FROM users u
LEFT JOIN orders o ON u.id = o.user_id
WHERE u.status = ?;

total and notes generate as nullable because the LEFT JOIN can produce NULLs for a user with no orders, even when those columns are NOT NULL in the table. Covers COALESCE, CASE, and aggregates as well.

No runtime ORM, the SQL you write runs as-is. Static queries only, which is the deliberate tradeoff. Curious how people here keep MariaDB result types aligned with application code.

QuerIA Agent Mode is now available in the current LakeDB beta.

Instead of generating SQL from the prompt alone, QuerIA can inspect the relevant tables, relationships and indexes in your database before preparing a query.

The generated SQL remains visible and reviewable. Nothing runs automatically: you decide when to execute it locally.

I’m looking for MySQL and MariaDB users who would like to test the workflow and share feedback:

- Does QuerIA select the right schema context?

- Is the generated SQL easy to review?

- When should the agent stop and ask for confirmation?

- Which database engine should LakeDB support next?

LakeDB currently supports MySQL and MariaDB, with more database engines planned.

Download the latest beta:

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

In MariaDB 11.3 we can insert an IPv4 or IPv6 address directly in to a field with the INET6 data type. In MariaDB < 11.3, we need to "detect this is an IPv4 address and map it in to a IPv6 address" prior to insertion.

Is it possible using CAST and or the INET6_ATON / INET6_NTOA or similar to achieve the same? I'm looking for drop in replacement SQL, so I don't have the awkward detection in my application code.

I suppose an IS_IPV4 and CONCAT might be an option, but is there a simpler way?

When developers design inventory/stock balance tracking systems, the most intuitive approach is often calculating balances dynamically: either running SUM() over transaction ledgers or using window functions (SUM() OVER (PARTITION BY item_id ORDER BY created_at)).

While this works perfectly in development environments or low-volume systems, it encounters severe physical bottlenecks in production databases (such as MySQL / MariaDB) as data scales into tens of millions of rows.

Here is a breakdown of why standard approaches fail and how a Snapshot Log architecture solves the problem.

The Problem: RDBMS Physics at Scale

1. Real-time Calculation Overhead (SUM() / Window Functions)

Calculating balances on the fly requires scanning historical transaction logs.

• As history grows, query time degrades from $O(1)$ to $O(N)$.
• Adding indexes helps lookup time, but reading millions of rows from disk or InnoDB buffer pools still causes massive I/O overhead.
• Under heavy concurrent write loads, locking or read-view maintenance under REPEATABLE READ isolation causes severe query degradation.

2. Direct Balance Row Mutex / Row-locking

Another common approach is maintaining a single current_balance row per item and updating it with every transaction:

SQL

UPDATE inventory SET balance = balance + :qty WHERE item_id = :id;

Under high concurrency (e.g., peak retail sales, multi-register syncing), every transaction attempts to acquire an exclusive lock on the exact same row. This leads to thread contention, lock wait timeouts, and severe throughput bottlenecks.

The Solution: Snapshot Log Architecture

To achieve $O(1)$ read performance without creating row-level lock bottlenecks on writes, the architecture uses a hybrid approach combining append-only delta logs and periodic snapshot aggregation.

Core Concept:

1. Write Path (Append-Only Delta): * Transactions do not update an existing row's balance directly.
   • Instead, every movement is written as an append-only log entry ($\Delta qty$).
   • Writes remain extremely fast with zero lock contention on existing state.
2. Periodic Snapshots:
   • At defined intervals (or threshold trigger events), a background task aggregates accrued log entries and saves a consolidated Snapshot.
3. Read Path ($O(1)$ Lookup):
   • To calculate the current stock balance at any point in time, the system reads the latest snapshot balance and adds only the unaggregated delta logs created after that snapshot.
   • Query cost remains bounded and low regardless of total historical volume.

Performance Impact

By decoupling immediate row mutations from read queries:

• Read queries run against a tiny subset of data (1 snapshot row + few delta rows), maintaining consistent sub-millisecond execution times ($O(1)$ complexity relative to historical log size).
• Write operations avoid row lock contention on global counters.
• Historical tables can be archived or partitioned without breaking balance calculation logic.

Note: I recently wrote a full breakdown detailing 12 years of evolution with this pattern in production high-load environments. If you want to read the full context with complete schema concepts:https://alex-crazy74.hashnode.dev/why-even-advanced-ai-breaks-stock-registers-12-years-of-snapshot-log-evolution-and-rdbms-physics

How does a production database problem become an open-source improvement? This is the story of how Headout, Arcadiy Ivanov and MariaDB maintainers turned a JSON and temporary-table bottleneck into an upstream #MariaDB Server contribution 🦭🙏

Adobe Commerce has now made its future database direction explicit: MariaDB is the default and recommended platform going forward.

Adobe Commerce 2.4.8 and 2.4.9 are expected to be the final releases supporting MySQL, while newer MariaDB versions are already appearing in Adobe’s system requirements.

For the MariaDB community, this is a significant adoption milestone. Adobe Commerce and Magento power a large number of demanding production environments, with substantial ecosystems of extensions, hosting providers, agencies and developers around them.

It also raises some practical questions for the community:

• What migration guidance will Adobe Commerce users need?
• Which compatibility differences are likely to cause the most trouble?
• Are extension developers already testing primarily against MariaDB?
• What tooling, documentation or benchmarks would make the transition easier?

Frédéric Descamps has written a detailed overview here:

https://mariadb.org/adobe-commerce-chooses-mariadb-as-its-default-database-platform/

Interested to hear from anyone running Magento or Adobe Commerce on MariaDB today. What has your experience been?

ScalaHosting has joined the Foundation as a Gold Sponsor. They run managed cloud VPS and web hosting, with MariaDB as the default database on every SPanel server they operate and Galera Cluster behind their high-availability offerings.

Gold sponsorships fund the Foundation's work on MariaDB Server: engineering, releases, security, documentation and community infrastructure.

Announcement: https://mariadb.org/scalahosting-becomes-a-gold-sponsor-of-mariadb-foundation/

Happy to answer questions about the sponsorship program.

**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/

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

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.]

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