<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:media="http://search.yahoo.com/mrss/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:lab="https://labradorcms.com/ns/rss" version="2.0">
  <!-- Source: https://www.theregister.com/headlines.atom -->
  <channel>
    <title>www.theregister.com - Articles</title>
    <link>https://siftrss.com/f/DoJGk1pZo5</link>
    <description>Articles from www.theregister.com</description>
    <item>
      <guid isPermaLink="true">https://www.theregister.com/a/5280975</guid>
      <link>https://www.theregister.com/databases/2026/07/30/mariadb-again-faces-questions-over-galeras-open-source-future/5280975</link>
      <pubDate>Thu, 30 Jul 2026 13:01:00 +0200</pubDate>
      <title>MariaDB again faces questions over Galera's open source future</title>
      <description><![CDATA[ Support for the MySQL build ends in September as the company develops separate premium replication technology ]]></description>
      <category>databases</category>
      <lab:kicker><![CDATA[ DATABASES ]]></lab:kicker>
      <dc:modified>Thu, 30 Jul 2026 11:28:56 +0000</dc:modified>
      <content:encoded><![CDATA[ With support for MySQL Galera Cluster ending in two months, open source observers are again questioning how much of the technology's future MariaDB plc intends to keep in the community edition. The company says Galera remains a core, open source component of MariaDB while it develops separate replication capabilities for enterprise customers. In March, MariaDB, the company behind the database forked from MySQL, reversed course and announced that MariaDB Community Server 12.3 would continue to include the Galera Cluster libraries. Galera is GPLv2-licensed database clustering technology created by Codership Oy, which MariaDB plc acquired in May 2025. Developers had previously noticed the clustering libraries were being removed from future versions of MariaDB Community Server, the open source database stewarded by the MariaDB Foundation. Frédéric Descamps, open source evangelist at the MariaDB Foundation, said at the time that there had been a "friendly reset" in the company's relationship with the open source community. He added that the concerns about the future of Galera in MariaDB were a "predictable outcome of people caring about continuity." Those concerns have resurfaced as the September 30 end-of-life date approaches for MySQL Galera Cluster. Announcing the decision in December, Max Mether, co-founder and vice president of server product management at MariaDB plc, urged users to migrate, saying: "This extended timeline gives your team ample opportunity to leverage the new in-place migration method and secure your future with MariaDB Galera Cluster." He also said the company was focusing innovation and new feature development exclusively on MariaDB Galera Cluster. "This consolidation allows the combined engineering team to deliver more powerful and advanced clustering features, ensuring industry-leading high availability for MariaDB," he said. Others have questioned whether migrating from MySQL to MariaDB is a price worth paying to remain with Galera. In a social media post, Marco Tusa, MySQL Technical leader at open source consultancy Percona, said: "Migrating to MariaDB isn't a simple 'drop-in' binary swap. Years of divergence in data dictionaries, [transaction] formats, and system tables mean moving to MariaDB is essentially adopting a completely different database." Percona provides its own alternative clustering technology for MySQL, XtraDB Cluster (PXC), which it says is open source with no proprietary hurdles. The consultancy also maintains its own tracking fork of Galera with critical stability fixes. In response, Descamps said that for users who specifically want to remain on the MySQL codebase, PXC proposes an "understandable and practical transition." However, he added that remaining aligned with upstream MySQL would leave users dependent on Oracle's long-term decisions for the database. "It may be the most convenient path for preserving today's MySQL compatibility, but that does not automatically make it the clearest long-term open source strategy," he said. He added: "most of the team that worked on Galera" appear to be developing a more enterprise solution. "Will that become open source one day? That's not the current direction.". Other open source developers would be free to add to Galera, "but currently, the previous Codership team is working on something different," he said. Vikas Mathur, chief product officer at MariaDB plc, said in a statement: "Innovation in the MySQL ecosystem has stalled, and users know it. MySQL customers are actively looking for a database that's moving forward, and that's exactly what we're offering. With the original Galera team now a part of MariaDB, moving to MariaDB Galera Cluster is an upgrade, not a workaround, and we've given users an extended runway through September 2026, plus a near-zero-downtime migration path, to make the move with confidence." The Register understands that maintaining a separate MySQL build no longer fits MariaDB plc's commercial focus. The company nevertheless insists that Galera remains a core component of its platform. Separately, MariaDB is developing proprietary replication capabilities for demanding enterprise use cases. The company says this work follows a distinct development path from open source Galera and will be offered as a premium feature. ® ]]></content:encoded>
      <enclosure url="https://image.theregister.com/?imageId=5281055&amp;width=800" type="image/jpeg"/>
      <media:thumbnail url="https://image.theregister.com/?imageId=5281055&amp;width=800"/>
    </item>
    <item>
      <guid isPermaLink="true">https://www.theregister.com/a/5279835</guid>
      <link>https://www.theregister.com/databases/2026/07/29/after-rewriting-sqlite-in-rust-turso-turns-its-sights-on-postgres/5279835</link>
      <pubDate>Wed, 29 Jul 2026 13:28:00 +0200</pubDate>
      <title>After rewriting SQLite in Rust, Turso turns its sights on Postgres</title>
      <description><![CDATA[ Cloud database upstart wants one virtual machine core to power multiple SQL frontends ]]></description>
      <category>databases</category>
      <lab:kicker><![CDATA[ DATABASES ]]></lab:kicker>
      <dc:modified>Wed, 29 Jul 2026 11:15:50 +0000</dc:modified>
      <content:encoded><![CDATA[ Having built a SQLite-compatible database from scratch in Rust, cloud database provider Turso is attempting something more ambitious: a Postgres-compatible implementation on the same foundation. "I don't think there is anything fundamentally wrong with Postgres. If there was something wrong with Postgres, we wouldn't rewrite it," Turso CEO Glauber Costa told The Register. But, like SQLite, Postgres could be freshened up for the cloud-native era. Turso has grander ambitions than putting another notch on the Rustbelt. Its SQLite reimplementation, originally codenamed Limbo and later renamed Turso, uses a virtual machine architecture that the company believes can support multiple database frontends. This month, Turso-the-company launched the Postgres effort and suggested that the same architecture could eventually support frontends for systems such as MySQL and Redis. "Turso is becoming the LLVM of databases. One modern, reliable core; many database frontends compiled down onto it," Costa wrote, announcing the release. From fork to rewrite Costa and fellow co-founder Pekka Enberg got the idea for Turso while studying the architecture of SQLite itself. Both had just left technical engineering jobs at ScyllaDB to start a San Francisco startup called ChiselStrike. They needed an online database, and SQLite was an obvious choice, but it needed updating to work as a cloud service. Software developer D. Richard Hipp created SQLite in 2000 as a compact, standalone transactional SQL engine. Hipp has steadfastly kept the scope of SQLite minimal, refusing outside contributors or bloating it with additional features (much like Andrew Tanenbaum kept tight control on Minix, inspiring a young Linus Torvalds to create a much more ambitious Linux). ChiselStrike forked SQLite as libSQL to give the company's developers the ability to modify the database system. It also provided a much-requested avenue for outside contributors to add their own features. At first, contributors added features without making many changes to SQLite's core – not exactly a weekend job, even for an ambitious hacker. More fundamental work, such as introducing a richer type system, would require ChiselStrike to tackle the engine itself. The company therefore launched a complete rewrite, initially codenamed Limbo. By then, ChiselStrike had already pivoted to a SQLite-based cloud service and renamed itself Turso. Limbo later became an official company project, adopted the Turso name – after the mythical Finnish sea creature Iku-Turso – and became the planned foundation for its future database engines. Behind the SQL While rewriting SQLite, the duo focused on its virtual machine architecture and concluded that the same approach could be expanded into a more general database execution engine. The software compiles SQL queries into its own bytecode language, called the Virtual Database Engine (VDBE). They built Turso using the same virtual machine design, one based on VDBE. This foundation could work not only to mimic SQLite, but any database system. "Look close enough, and every SQL database is just a fancy collection of B-Trees with a bunch of Indexes," Costa wrote. Any features that Postgres has but SQLite lacks could be written with VDBE. To demonstrate that their VM was sufficiently expressive, the duo built a demo that runs the 1990s classic video game DOOM in WebAssembly, with each rendered frame returned as a result row. There are similar approaches to virtualizing the database. Google's Spanner can offer different modalities, spanning relational, graph, key-value, vector and other formats. Microsoft built the Cosmos database service on a similar premise. Spanner and Cosmos operate higher up on the stack than Turso, Costa explained. Closer to Turso's building block style is Apache DataFusion, also built with Rust. "The idea of a database that can speak multiple models is nothing new," Costa said. "What is different about Turso is that it sits at the lowest possible level, exactly one layer above the storage engine." Postgres on top, Turso under Enberg and Costa put together a Postgres-compatible prototype on top of Turso called pgmicro. Now came the hard work of making it ready for production use. "Essentially we would offer a database that speaks Postgres, that plays the same role as Postgres, that is familiar to the developers in the Postgres ecosystem, but it's built in a different way underneath," Costa said. When sufficiently mature, this Postgres-flavored Turso is intended to run most existing applications without modification, although the company is not promising complete compatibility with the OG Postgres. It also plans enhancements including automatically updated materialized views, a frequent request from the Postgres community. One aspect of the old Postgres that may be jettisoned will be its one-process-per-connection model, which can be very expensive, computationally. "It's worth a fresh look," Costa said. While Postgres will require more work, it's not an order-of-magnitude more work, and the new features can be rolled back into Turso for use in other database variants down the road. On the commercial side, Turso is building out a database-as-a-cloud service that will offer any DB flavor the customer would want, but all running on Turso. Rust and AI on Turso Rewriting open source software in the Rust programming language has become a sport, with official and unofficial rewrites underway of Kubernetes, the Bun JavaScript tool chain, and bits of Linux. Much of this work has been done with AI, which has a pretty good grasp of Rust fundamentals. But for Turso, Costa doesn't ascribe too much significance to the choice of the language for the rewrite. Rust offers memory safety, yet plenty of Postgres bugs have nothing to do with memory safety. Rust works well with AI, which Turso uses quite a bit, but Costa and Enberg chose Rust for Turso before AI coding agents became widespread. "I never understood the fascination programmers have with programming languages," he said, adding: "For us, Rust is just a tool." ® ]]></content:encoded>
      <enclosure url="https://image.theregister.com/?imageId=1682034&amp;width=800" type="image/jpeg"/>
      <media:thumbnail url="https://image.theregister.com/?imageId=1682034&amp;width=800"/>
    </item>
  </channel>
</rss>
