What's Oracle really doing with MySQL?

For those that wonder what is really going on with MySQL inside Oracle I invite you to read Tomas Ulin Inside MySQL Blog

Stayed tuned for more to come later.

Comments

Post a Comment

Popular posts from this blog

Under Construction: Building the MariaDB Benchmarking Test Automation Framework (TAF)

Image
Building a New Test Automation Framework for MariaDB MariaDB has given me the chance to pursue a lifelong dream: creating a new Test Automation Framework (TAF) — an improved, expanded evolution of the Autobench3 framework I originally built for MySQL. Autobench3 was never just a benchmark API. It was a framework that wrapped benchmark APIs to provide a consistent platform for configuration and abstraction. Instead of requiring deep knowledge of each benchmark tool, Autobench3 allowed developers to work with simple command‑line options and property files. The framework made clear what suite was being run, what test case was in play, which database software was targeted, and what overrides were applied. When running, the framework would load the chosen test suite into itself — becoming Sysbench, becoming DBT2 — and then drive the workload through a consistent set of lifecycle stages. Autobench3: Still in Service, But Limited Autobench3 continues to serve MySQL well in worklog d...
Read more

Cold Comfort: When PostgreSQL Protects Your Data by Locking You Out

Cold Comfort: When PostgreSQL Protects Your Data by Locking You Out PostgreSQL’s MVCC architecture is designed to preserve data integrity at all costs. But when autovacuum falls behind, that protection can come at a steep operational price: your data is still there — but you can’t write to it, and in some cases, you can’t even access it. Over the past three years, PostgreSQL has experienced multiple production-halting outages across major cloud providers and enterprise deployments. The root cause in every case? Vacuum lag. Three Confirmed Outages (2024–2025) AWS RDS PostgreSQL Wraparound Incident Date: December 2024 (updated February 2025) Impact: PostgreSQL entered read-only mode Cause: Transaction ID wraparound protection triggered due to autovacuum lag Recovery: Required emergency vacuuming and downtime Source: AWS Blog Google Cloud SQL PostgreSQL Lockouts Date: Throughout 2024 Impact: PostgreSQL refused new t...
Read more

Why PgBouncer Is Essential for Fair PostgreSQL vs MariaDB Benchmarking

Image
If you're benchmarking PostgreSQL against MariaDB, you're not comparing apples to apples unless you introduce PgBouncer . Here's why. Connection Architecture PostgreSQL spawns a full process per client connection. That means every incoming connection forks a new backend, each with its own memory map, file descriptors, and kernel overhead. On a high-core host, this model hits system limits fast—either process count or scheduler overhead. To scale efficiently, PostgreSQL requires PgBouncer , a separate connection pooling proxy. It’s an external add-on—you have to install it, configure it, and monitor it independently. MariaDB , by contrast, uses a thread-per-connection model natively . No add-ons, no proxies. Thread pooling is built into the server and enabled out of the box. Threads are lightweight, share memory space, and scale efficiently. With proper stack tuning, MariaDB can handle tens of thousands of concurrent connections without breaking a sweat. PgBouncer...
Read more