Author: Renato Losio

AWS recently announced exportable public SSL/TLS certificates from AWS Certificate Manager, addressing a long-standing community request. This update allows users to export certificates along with their private keys for use beyond AWS-managed services.

Exportable public certificates enable customers to deploy ACM-issued certificates on Amazon EC2 instances, containers, and on-premises hosts, supporting AWS, hybrid, and multicloud workloads. Channy Yun, lead blogger at AWS, explains:

The exportable public certificates are valid for 395 days. There is a charge at time of issuance, and again at time of renewal. Public certificates exported from ACM are issued by Amazon Trust Services and are widely trusted by commonly used platforms such as Apple and Microsoft and popular web browsers such as Google Chrome and Mozilla Firefox.

Previously, users could only create public certificates within AWS Certificate Manager or import certificates issued by third-party certificate authorities (CAs) for use with AWS services, such as Elastic Load Balancing (ELB), CloudFront, and API Gateway. However, there was no way to export these certificates or create and manage certificates for external services or EC2 instances.

Corey Quinn, chief cloud economist at The Duckbill Group, published a long article, “AWS Certificate Manager Has Announced Exportable TLS Certificates, and I’m Mostly Okay With It,” reviewing the new feature. Quinn writes:

The pricing is quite reasonable. It costs either $15 per domain, or $149 for a wildcard certificate. That seemed a bit expensive to me, until I remembered what these things used to cost–and apparently still do. $400 per certificate isn’t at all uncommon from trustworthy vendors (…) ACM’s pricing is a comparative steal.

While many cloud practitioners question the benefits of the new solution over free options like Let’s Encrypt, Wojtek Szczepucha, solutions architect at AWS, highlights the main targets of the announcement:

Meeting regulations and compliance from a governance perspective. Simpler to manage from an operations perspective. It’s not invented out of thin air, but rather based on customers asking for it.

While the ability to export has been well received by the community and the new certificates are currently valid for over a year, the SSL/TLS certificate lifespans are expected to shrink to 200 days next year, 100 days in 2027, and only 47 days by 2029, as previously reported on InfoQ. When customers renew certificates on AWS Certificate Manager, they are charged for a new certificate issuance. Yun adds:

You can configure automatic renewal events for exportable public certificates by Amazon EventBridge to monitor certificate renewals and create automation to handle certificate deployment when renewals occur. (…) You can also renew these certificates on-demand.

Quinn warns:

At least at launch, this feature doesn’t support ACME for automatic renewal, which means there’s likely to be an inherently manual process to renew them. While you can automate the entire certificate issuance dance via AWS APIs, I’ve worked with enough enterprise software to know how this is going to play out: it’s a manual process.

Customers have to choose to make a certificate exportable before it’s issued, and there is no option to go back and retroactively export certificates that are already in use. This ensures that there is no default export of certificates with their private keys.

The ability to issue exportable public certificates was one of the main announcements of the recent re:Inforce conference. During the 3 days in Philadelphia, the cloud provider introduced other new security capabilities and services, including multi-party approval for logically air-gapped vaults in AWS Backup and the new AWS Security Hub for risk prioritization and response at scale.

MariaDB has recently released MariaDB Community Server 11.8 as generally available, its yearly long-term support (LTS) release for 2025. The new release introduces integrated vector search capabilities for AI-driven and similarity search applications, enhanced JSON functionality, and temporal tables for data history and auditing.

The new Vector datatype allows for more complex data storage and retrieval, particularly useful for machine learning and data science applications where vector representations of data are common. While vector support was added in earlier releases, as previously covered on InfoQ, this is the first LTS release to allow developers to store embeddings and query them alongside traditional relational data. Kaj Arnö, CEO of the MariaDB Foundation, writes:

This is undoubtedly the most significant highlight of MariaDB 11.8 LTS: full support for MariaDB Vector(…) Vector search capabilities are crucial for RAG and other modern AI and machine learning applications, enabling similarity search on large datasets. MariaDB Vector is now fully supported in LTS form, giving you stability and predictability for years to come.

MariaDB Vector includes a native VECTOR data type with indexing for nearest-neighbor search, functions for calculating vector similarity (VEC_DISTANCE_EUCLIDEAN, VEC_DISTANCE_COSINE, and VEC_DISTANCE), and functions for converting binary vectors to their textual representation and back (VEC_FromText and VEC_ToText). Furthermore, the feature provides SIMD hardware optimizations for Intel (AVX2 and AVX512), ARM, and IBM Power10 CPUs.

The new features allow similarity searches on high-dimensional data, targeting popular use cases like semantic search, recommendation engines, and anomaly detection. Earlier this year, database expert Mark Callaghan ran benchmarks to compare MariaDB, Qdrant and Postgres (pgvector) with a large dataset. He concluded:

If you already run MariaDB or Postgres then I suggest you also use them for vector indexes (…) I have a bias. I am skeptical that you should deploy a new DBMS to support but one datatype (vectors) unless either you have no other DBMS in production or your production DBMS does not support vector indexing.

In a deep review of the release, Federico Razzoli, founder of Vettabase, highlights some of his favorite improvements, including parallel dumps, PARSEC authentication, and new SQL syntaxes, as well as what was left out, such as catalogs. On vector search, he writes:

MariaDB vectors are faster than pgvector, according to Mark Callaghan’s benchmarks. But there are some caveats here. If we only care about performance, the biggest problem is that MariaDB apparently decided to never implement stored procedures in languages other than SQL. This means that the embedding process must happen outside of MariaDB, normally in another server, even if the original data is in MariaDB. With PostgreSQL, you can do everything in Postgres itself.

Vector search is the main feature of the MariaDB release but not the only one: like other open-source relational databases, MariaDB has now moved to Unicode as the default character set to make it fully compatible with today’s multilingual and global applications, and extended the TIMESTAMP range from 2038 to 2106. Arnö writes:

Like most open source projects, we have addressed the famous Year 2038 problem. But unlike many others, MariaDB achieves this without requiring any data conversion — provided you’re not using System-Versioned Tables. This means your existing data stays intact while you gain an 80-year reprieve on timestamp overflows.

The release includes improved support for temporal tables for data history and auditing: maintaining a complete history of modifications to the data helps with Point-in-Time Recovery scenarios, compliance, and security. Ralf Gebhardt, product manager at MariaDB plc, writes:

First introduced in MariaDB 10.3 and now available with several enhancements, Temporal Tables automatically manages the history of your data and simplifies the development and maintenance of applications that require data lineage.

According to the documentation, it is possible to upgrade to MariaDB 11.8 from MariaDB 11.4 (the previous LTS) or any older release, back to MariaDB Server 10.0 or earlier, including most versions of MySQL Server. MariaDB has published a separate article on how to build AI applications using frameworks with MariaDB Vector Store.

Major cloud providers do not yet support the latest GA release on their managed services, with AWS currently supporting 11.8 only in the database preview environment.

Released under the GPLv2 license, MariaDB 11.8 is available on GitHub.

The recent article by Zhou Sun, “HTAP is Dead,” sparked a debate in the data community about the future of hybrid transaction/analytical processing. HTAP was meant to help integrate historical and online data at scale, supporting more flexible query methods and reducing business complexity.

In the article, Sun, co-founder and CEO at Mooncake Labs, argues that the long-promised vision of unifying transactional and analytical workloads in a single system has failed to materialize. Gartner introduced the term HTAP (Hybrid Transactional and Analytical Processing) over a decade ago, announcing it as “the next big DB architecture,” where the goal was to close the gap between operational and analytical systems.

The article tracks the history of how OLTP and OLAP database workloads started as one in the 1970s, became separated a decade later, with HTAP attempting to merge them again in the 2010s. Sun believes that practical challenges like resource contention, complexity, and evolving hardware architectures make dedicated, specialized systems a more viable path forward. Sun writes:

The cloud also started the move away from tightly coupled warehouses toward modular lakes built on object storage. In trying to escape the traditional warehouse/database, data teams started assembling their own custom systems.

HTAP was considered years ago a requirement for emerging workloads like pricing, fraud detection, and personalization, with SingleStoreDB and TiDB among the main players in the market. The author contends that cloud data warehouses like Snowflake and BigQuery emerged as the clear winners in the 2020s by focusing exclusively on analytical processing and separating storage from compute, which allowed for scalable, cost-effective solutions without the complexity of HTAP systems. Sun notes that while transactional databases have also evolved, they have largely remained separate from analytics, and attempts to merge the two have failed to gain broad adoption. Sun adds:

Even in today’s disaggregated data stack, the need remains the same: fast OLAP queries on fresh transactional data. This now happens through a web of streaming pipelines, cloud data lakes, and real-time query layers. It’s still HTAP; but through composition instead of consolidation of databases.

To move beyond traditional warehouses and databases, data teams are now assembling their own custom systems using what Sun calls “best-in-class” components. These architectures combine OLTP systems and stream processors as the write-ahead log (WAL), Iceberg as the storage layer, query engines such as Spark and Trino for data processing, and real-time systems like ClickHouse or Elasticsearch indexes. On Hacker News, Thom Lawrence, founder and former CTO of Statsbomb, writes:

You cannot say HTAP is dead when the alternative is so much complexity and so many moving parts. Most enterprises are burning huge amounts of resources literally just shuffling data around for zero business value. The dream is a single data mesh presenting an SQL userland (…) we are close but we are not there yet and I will be furious if people stop trying to reach this endgame.

Sun’s article sparked a debate in the community, with Peter Zaitsev, founder of Percona and open source advocate, summarizing:

There is no “one size fits all” – while large teams are realizing tight coupling is problematic, for small teams, small projects it is actually very convenient and practical to have a single database, which does “everything” reasonably well, as such I think HTAP makes a lot of sense as a feature, but probably not as a name as we need our databases to be more than just Analytical and Transactional.

Many data engineers now agree that the once-promising HTAP model is being reconsidered, with the growing success of PostgreSQL in recent years illustrating this shift. As technology evolves, new paradigms are challenging the relevance of HTAP in modern data architecture.

AWS has recently announced the general availability of the CDK Toolkit Library. This new Node.js library allows developers to programmatically control the CDK to build additional automation around the CDK, exposing classes and methods to synthesize, deploy, and destroy stacks, among other capabilities.

The CDK Toolkit Library enables developers to perform CDK actions programmatically through code, rather than relying on CLI commands. Currently supported only in TypeScript, the library can be used to create custom tools, build specialized CLI applications, and integrate CDK capabilities into existing development workflows. Adam Keller, senior cloud architect at AWS, explains the main goal of the project:

Until now, the primary way to interact with the AWS CDK was through the CDK CLI, which presented challenges when building automation around the CDK as users couldn’t directly interact with the CDK toolkit natively in their code.

According to the documentation, the CDK Toolkit Library is suited for advanced infrastructure deployments, including automation within CI/CD pipelines, the creation of custom validation or approval steps, and the implementation of patterns across multiple environments.

The AWS CDK is an open-source framework that enables the definition of cloud infrastructure in code and its subsequent provisioning through AWS CloudFormation. It includes two main components: a class library for modeling infrastructure and a toolkit that provides either a command-line interface or a programmatic library to operate on those models.

The new Node.js library provides programmatic interfaces for the following six CDK actions: Synthesis, to generate CloudFormation templates and deployment artifacts; Deployment, to provision or update infrastructure; List, to view information about stacks and their dependencies; Watch, to monitor CDK applications for local changes; Rollback, to return stacks to their latest stable state; and Destroy, to remove stacks and associated resources. Keller adds:

The AWS CDK Toolkit Library opens up a whole new range of possibilities for platform engineers and developers who need finer grained control over how and when their infrastructure is deployed and tested.

Among the example scenarios provided, AWS highlights the automatic validation of application logic, maintaining ephemeral environments for integration or end-to-end testing, and cleaning up resources immediately after test completion to reduce cloud costs and configuration drift. Ran Isenberg, principal software architect at CyberArk and AWS Hero, comments:

While it’s a step in the right direction, I don’t think it replaces the deploy script we wrote to every stack. We have so many options that the CDK toolkit will not support, as it’s too specific to our needs and configurations.

More details are available on GitHub, including options to report bugs, provide feedback, share ideas, and request new features. The community has suggested exposing additional classes and functionalities, such as EnvironmentAccess, as potential future enhancements.

The CDK Toolkit Library is available in all regions where the AWS CDK is supported. A getting-started page provides instructions on how to install, configure, and customize the library.

The OpenSearch Software Foundation has announced the general availability of OpenSearch 3.0, the first major release in three years and the first since the project joined the Linux Foundation. This version introduces native support for the Model Context Protocol (MCP), along with pull-based data ingestion and gRPC support, aimed at improving scalability and integration.

OpenSearch was launched in 2021 by AWS as a fork of Elasticsearch 7.10, following Elastic’s license change. With performance as a key focus of this release, OpenSearch 3.0 delivers up to 9.5x faster vector search compared to version 1.3, thanks to support for GPU acceleration and more efficient indexing.

OpenSearch 3.0 upgrades to Apache Lucene 10 and introduces enhancements to data ingestion, transport, and management. James McIntyre, senior product marketing manager at AWS, Saurabh Singh, engineering leader at AWS, and Jiaxiang (Peter) Zhu, senior system development engineer at AWS, explain:

The latest version of Apache Lucene offers significant improvements in performance, efficiency, and vector search functionality. These types of improvements pave the way for larger vector and search deployments, enabling AI workloads to scale factorially over time.

Lucene 10 introduces improvements in both I/O and search parallelism, and requires JVM version 21 or later—resulting in some breaking changes and prompting a major version update. Elasticsearch, which reverted to an open source model under the AGPL license last year, recently released version 9.0.0-rc1, which also supports the latest version of Lucene.

The latest OpenSearch release also adds support for gRPC and pull-based ingestion, and introduces reader-writer separation. This allows indexing and search workloads to be configured independently, ensuring consistent, high-performance operation for each. McIntyre, Singh, and Zhu add:

Benefiting from underlying HTTP/2 infrastructure, gRPC supports multiplexing and bidirectional data streams, enabling clients to send and receive requests concurrently over the same TCP connection. Performance gains can be especially pronounced for users working with large and complex queries, where the overhead of deserializing requests can compound when using JSON.

OpenSearch now also supports index type detection and integrates the dynamic data management framework Apache Calcite, enabling iterative query building and exploration. This is achieved by incorporating the query builder into OpenSearch SQL and PPL. In a popular thread on Hacker News, Joe Johnston writes:

Elastic still has the edge on features. Especially Kibana has a lot more features than Amazon’s fork (…) A lot of my consulting clients seem to prefer Opensearch lately. That’s mainly because of the less complicated licensing and the AWS support.

Comparing OpenSearch and Elasticsearch, user Macha adds:

One thing that Opensearch misses that would have been very nice to have on a recent project is enrich processors.

OpenSearch is open source under the Apache 2.0 license. More details about the latest release are available in the release notes on GitHub.

Last month, Synadia threatened to pull NATS from the Cloud Native Computing Foundation (CNCF), moving from the Apache 2.0 license to a non-open source license. While the dispute lasted only a few days, with both Synadia and CNCF agreeing that the project remains in the open source ecosystem, the dispute left many concerned about the long-term availability and support of open source projects.

NATS is an open source messaging system that enables secure, high-performance, and scalable communication between distributed systems and services. After developing and maintaining the project under the Apache 2.0 license for many years, and donating it to the CNCF in 2018, Synadia announced last month its plan to withdraw the NATS server from the foundation and adopt the Business Source License (BUSL), a non-open source license. Derek Collison, creator of NATS.io and CEO of Synadia, wrote:

For the NATS ecosystem to flourish, Synadia must also thrive. This clarity has guided our decision-making and planning (…) Synadia’s customers, partners, and the broader NATS ecosystem derive tremendous value from the features and capabilities of the NATS server. Synadia and its predecessor company funded approximately 97% of the NATS server contributions.

While a discussion about the future of the project was taking place in the CNCF TOC repository, the foundation explained why the open source commitments and principles were under threat and disputed the ownership of the NATS trademark, sparking concerns about the future of the popular project. Foundation-backed open source software has traditionally offered greater stability than corporate-owned projects, making NATS’ potential departure from CNCF a significant exception.

After a few days of discussions and updates, Synadia and the CNCF announced on May 1st that they had reached an agreement: Synadia would transfer the NATS trademark registrations to the Linux Foundation, without forking the project, while the CNCF would retain control over the project’s infrastructure and assets. If Synadia chooses to fork the project for a proprietary offering in the future, it will have to do so under a new name.

In the article “OSS: Two Steps Forward, One Step Back,” Stephen O’Grady, principal analyst and cofounder at RedMonk, writes:

The flareup starkly revealed traditional fault lines in the wider open source community around the role of foundations. For many, this situation provided an opportunity not to protest the alleged about face but rather to attack foundations generally and the CNCF specifically for their shortcomings, both perceived and real (…) Vendors that choose to donate projects to foundations do so understanding, or at least should, that donation is a one way door.

Discussing “NATS goes Nuts – Quite Unique Open Source controversy,” Peter Zaitsev, founder of Percona and open source advocate, adds:

There’s a lesson here for the CNCF too. If it wants people to trust the projects it hosts, it needs to make sure situations like this don’t happen. That means locking down all the key assets -like trademarks and licensing rights- before fully accepting a project.

Discussing the future of Synadia and the NATS project after the agreement was reached, Collison explained how Synadia is now considering a commercial distribution that would embed the OSS NATS Server targeted for specific use cases, with the company still providing commercial support for the open source solution. O’Grady concludes:

The NATS storm was a black eye for open source broadly. Between the simmering antagonism towards foundations at scale, the direct attacks on the CNCF specifically and the revelations about NATS’ performance and Synadia’s alleged behaviors, it was not a great week for open source.

Seven years after joining the CNCF, NATS has yet to achieve “graduated” status and continues to operate under the “incubating” designation, one of the factors that contributed to the dispute.

Redis 8 has recently hit general availability, switching to the AGPLv3 license. A year after leaving its open source roots to challenge cloud service providers and following the birth of Valkey, Redis has rehired its creator and moved back to an open source license.

Initially released under the more permissive BSD license, Redis switched to the more restrictive and not open source SSPLv1 license in March 2024, sparking concerns in the community and triggering the successful Valkey fork. Just over a year later, the project’s direction has changed again, and Redis 8.0 is once more open source software, this time under the terms of the OSI-approved AGPLv3 license.

According to Redis’ announcement, the new major release delivers several performance improvements, including up to 87% faster commands, up to 2× higher throughput in operations per second, and up to 18% faster replication. It also introduces the beta of Vector Sets, which is discussed separately on InfoQ. Salvatore Sanfilippo (aka ‘antirez’), the creator of Redis, explains:

Five months ago, I rejoined Redis and quickly started to talk with my colleagues about a possible switch to the AGPL license, only to discover that there was already an ongoing discussion, a very old one, too. (…) Writing open source software is too rooted in me: I rarely wrote anything else in my career. I’m too old to start now.

A year ago, the more restrictive license triggered different forks of Redis, including the very successful and CNCF-backed Valkey that gained immediate support from many providers, including AWS and Google Cloud. AWS has launched ElastiCache for Valkey and MemoryDB for Valkey at significant discounts compared to their ElastiCache for Redis version offering.

While noting that Valkey is currently outperforming Redis 8.0 in real-world benchmarks, Khawaja Shams, CEO and co-founder of Momento, welcomes Sanfilippo’s return to Redis and writes:

I am genuinely excited about his return because it is already impactful. He’s following through on his promise of contributing new features and performance optimizations to Redis. More profoundly, Redis 8.0 has been open-sourced again.

While many predict that developers using Valkey will not switch back to Redis, they also acknowledge that Valkey will face tougher competition. Peter Zaitsev, founder of Percona and open source advocate, highlights one of the advantages of Redis:

While a lot has been said about Redis going back to opensource with AGPLv3 License, I think it has been lost it is not same Redis which has been available under BSD license couple of years ago – number of extensions, such as RedisJSON which has not been Open Source since 2018 are now included with Redis under same AGPLv3 license. This looks like an important part of the response against Valkey, which does not have all the same features, as only the “core” Redis BSD code was forked

The article “Redis is now available under the AGPLv3 open source license” confirms that, aside from the new data type (vector sets), the open source project now integrates various Redis Stack technologies, including JSON, Time Series, probabilistic data types, and the Redis Query Engine into core Redis 8 under AGPL.

The new major release and licensing change have sparked popular threads on Reddit, with many practitioners suggesting it’s too late and calling it a sign of a previous bad decision. Some developers believe the project’s greatest asset remains its creator, while Philippe Ombredanne, lead maintainer of AboutCode, takes a more pessimistic view of the future:

Users see through these shenanigans. For Redis, the damage to their user base is likely already done, irreparable and the shattered trust never to be regained.

Redis is not the first project to switch back from SSPLv1 to AGPL following a successful fork and a loss of community support and trust. A year ago, Shay Banon, founder and CEO of Elastic, announced a similar change for Elasticsearch and Kibana, as reported on InfoQ.

PlanetScale has recently announced that vector support is now generally available. Created as a fork of MySQL, this new feature allows vector data to be stored alongside an application’s relational MySQL data, removing the need for a separate specialized vector database.

While PostgreSQL has been the default open-source choice for vector search, the company behind the Vitess database announced in 2023 its intention to fork MySQL and add vector search capabilities. Following a public beta in late 2024, vector search is now generally available with improved performance. Patrick Reynolds, software engineer at PlanetScale, writes:

Since the open beta began, we have doubled query performance, improved memory efficiency eight times, and focused on robustness to make sure vector support is as solid as every other data type MySQL supports.

The new vector capabilities enable direct support for recommendation systems, semantic search, and the now-popular RAG workloads on a MySQL-compatible engine. Reynolds adds:

We also built advanced vector-index features to satisfy a variety of embeddings and use cases. An index can rank vectors by Euclidian (L2), inner product, or cosine distance. It can store any vector up to 16,383 dimensions. It supports both fixed and product quantization.

According to the authors, a key differentiator of PlanetScale’s vector support is its ability to use indexes larger than RAM. The implementation is based on two papers from Microsoft Research: SPANN (Space-Partitioned Approximate Nearest Neighbors) and SPFresh. SPANN is a hybrid graph/tree algorithm that enables scaling to larger-than-RAM indexes, while SPFresh defines a set of background operations that maintain the index’s performance and recall.

While PlanetScale has designed the SPANN and SPFresh operations to be transactional and integrated them into MySQL’s default storage engine, there is little hope that Oracle will merge the change into the MySQL Community Edition. In a Hacker News thread during the beta period, Vicent Martí explained:

It’s already open source, because GPL requires it. It’s unlikely to be accepted as an upstream contribution given that Oracle has their own Vector type that is only available in their MySQL cloud service.

Writes and queries for the new feature work like a normal RDBMS, building an index with an ALTER or CREATE VECTOR INDEX statement, or writing SELECT statements with JOIN and WHERE clauses. Marti added:

The tight integration fundamentally means that inserting, updating and deleting vector data from MySQL is always reflected immediately in the index as part of committing your transaction. But it also means that the indexes are fully covered by the MySQL binlog; they recover from hard crashes just fine. They’re also managed by MySQL’s buffer pool, so they scale to terabytes of data, just like any other table. And also crucially, they’re fully integrated with the query planner, so they can be used in any query, including JOINs and WHERE clauses.

PlanetScale is built on top of Vitess, an open source database clustering system designed for the horizontal scaling of MySQL. A list of compatibility limitations is available online.

The team behind the distributed serverless database Fauna has recently announced plans to shut down the service by the end of May. While the managed database will be terminated soon and all customers will have to migrate to other platforms, Fauna is committing to releasing an open source version of the core database technology alongside the existing drivers and CLI tooling.

Started in 2011 as FaunaDB by the team that scaled Twitter by building its in-house databases and systems, Fauna tried for many years to combine the power of a relational database with the flexibility of JSON documents. Fauna was designed to scale horizontally within a data center to maximize throughput while easily spanning globally distributed sites, ensuring reliability and local performance. With the vision of enabling “applications without database limits” and claiming use by more than 80,000 development teams, the service has now reached the end of the road.

According to the Fauna Service End of Life FAQ, the Fauna service will be turned off on May 30th, and all Fauna accounts will be deleted. The team writes:

Driving broad based adoption of a new operational database that runs as a service globally is very capital intensive. In the current market environment, our board and investors have determined that it is not possible to raise the capital needed to achieve that goal independently.

Yan Cui, AWS Serverless Hero and serverless expert, writes:

Sad to see Fauna go. They were one of the first truly serverless databases on the market.

Ankur Raina, senior staff sales engineer at Cockroach Labs, summarizes:

The DB market is brutal (…) Getting large customers on Serverless databases is hard. (…) Fauna was trying to build the document model of MongoDB, consistency & geo distribution of CockroachDB but without any ability to run it beyond two cloud providers.

The sunsetting of a once-popular database has sparked many reactions within the community. In a popular Hacker News thread, Pier Bover, founder of Waveki, writes:

A decade ago it seemed that edge computing, serverless, and distributed data was the future. Fauna made a lot of sense in that vision. But in these years since, experimenting with edge stuff, I’ve learned that most data doesn’t really need to be distributed. You don’t need such a sophisticated solution to cache a subset of data for reads in a CDN or some KV. What I’m saying is that, probably, Cloudflare Workers KV and similar services killed Fauna.

User strobe adds:

I found Fauna very interesting from a technical perspective many years ago, but even then, the idea of a fully proprietary cloud database with no reasonable migration options seemed pretty crazy at the time. (…) Hope that something useful will be open sourced as a result.

Peter Zaitsev, open source advocate, questions instead:

While there is no alternative history, I wonder what would have happened if Fauna had chosen to start as Open Source, become 100x more widely adopted but monetize a smaller portion of their customers due to “competing” Open Source alternatives.

The market of distributed databases that once competed with Fauna includes Google Spanner, PlanetScale, CockroachDB, and TiDB, among others. A migration guide is now available, offering the option to create snapshot exports, with the exported data stored as JSON files in an AWS S3 bucket. For smaller collections, data can also be exported using FQL queries.

FerretDB has announced the first release candidate of version 2.0. Now powered by the recently released DocumentDB, FerretDB serves as an open-source alternative to MongoDB, bringing significant performance improvements, enhanced feature compatibility, vector search capabilities, and replication support.

Originally launched as MangoDB three years ago, FerretDB became generally available last year, as previously reported by InfoQ. Peter Farkas, co-founder and CEO of FerretDB, writes:

FerretDB 2.0 represents a leap forward in terms of performance and compatibility. Thanks to changes under the hood, FerretDB is now up to 20x faster for certain workloads, making it as performant as leading alternatives on the market. Users who may have encountered compatibility issues in previous versions will be pleased to find that FerretDB now supports a wider range of applications, allowing more apps to work seamlessly.

Released under the Apache 2.0 license, FerretDB is usually compatible with MongoDB drivers and tools. It is designed as a drop-in replacement for MongoDB 5.0+ for many open-source and early-stage commercial projects that prefer to avoid the SSPL license, a source-available copyleft software license.

FerretDB 2.x is leveraging Microsoft’s DocumentDB PostgreSQL extension. This open-source extension, licensed under MIT, introduces the BSON data type and related operations to PostgreSQL. The solution includes two PostgreSQL extensions: pg_documentdb_core for BSON optimization and pg_documentdb_api for data operations.

According to the FerretDB team, maintaining compatibility between DocumentDB and FerretDB allows users to run document database workloads on Postgres with improved performance and better support for existing applications. Describing the engine behind the vCore-based Azure Cosmos DB for MongoDB, Abinav Rameesh, principal product manager at Azure, explains:

Users looking for a ready-to-use NoSQL database can leverage an existing solution in FerretDB (…) While users can interact with DocumentDB through Postgres, FerretDB 2.0 provides an interface with a document database protocol.

In a LinkedIn comment, Farkas adds:

With Microsoft’s open sourcing of DocumentDB, we are closer than ever to an industry-wide collaboration on creating an open standard for document databases.

In a separate article, Farkas explains why he believes document databases need standardization beyond just being “MongoDB-compatible.” FerretDB provides a list of known differences from MongoDB, noting that while it uses the same protocol error names and codes, the exact error messages may differ in some cases. Although integration with DocumentDB improves performance, it represents a significant shift and introduces regression constraints compared to FerretDB 1.0. Farkas writes:

With the release of FerretDB 2.0, we are now focusing exclusively on supporting PostgreSQL databases utilizing DocumentDB (…) However, for those who rely on earlier versions and backends, FerretDB 1.x remains available on our GitHub repository, and we encourage the community to continue contributing to its development or fork and extend it on their own.

As part of the FerretDB 2.0 launch, FerretDB Cloud is in development. This managed database-as-a-service option will initially be available on AWS and GCP, with support for Microsoft Azure planned for a later date. The high-level road map of the FerreDB project is available on GitHub.