Appwrite and MongoDB make database choice a first-class part of self-hosted backend stacks
Original: We’re proud to announce @Appwrite's official partnership with @MongoDB. Starting with Appwrite 1.9.0, developers running Appwrite in self-hosted environments will be able to choose MongoDB as their database engine, alongside existing options. This partnership goes beyond self-hosting. At Appwrite, our vision has always been to meet developers where they are and give them flexibility at every stage of building and scaling their products. We know there is no single solution that works for every team. Together with the recent introduction of TablesDB, this collaboration creates a strong foundation for bringing more database options to our cloud platform over time and making Appwrite even more adaptable end-to-end. We’re excited to work closely with a company we believe has set the standard for modern databases, and we look forward to learning and collaborating with the MongoDB team as we continue pushing the boundaries of cloud development and open source. View original →
What Appwrite announced on X
On April 1, 2026, Appwrite founder Eldad Fux said on X that Appwrite and MongoDB had entered an official partnership. The immediate product change is concrete: starting with Appwrite 1.9.0, developers running Appwrite in self-hosted environments can choose MongoDB as the underlying database engine alongside existing options.
The wording matters because the post does not present MongoDB support as a one-off connector. Fux explicitly framed it as part of a broader strategy around flexibility. He said the partnership goes beyond self-hosting and, together with the recent introduction of TablesDB, creates a foundation for bringing more database options to Appwrite Cloud over time.
What Appwrite’s official materials add
Appwrite’s announcement blog fills in the product direction behind the post. The company describes the MongoDB relationship as a long-term strategic collaboration built around an open ecosystem, database flexibility, and a backend platform that developers can own end to end. The same post says Appwrite is now listed in the MongoDB Partner Ecosystem, which turns the announcement from simple compatibility into a formal platform relationship.
The self-hosting guide adds the implementation details. According to Appwrite’s documentation, choosing MongoDB during setup makes Appwrite spin up a MongoDB Community Edition container under the hood while preserving the same Appwrite APIs, SDKs, and console workflow. The guide also shows that this path ships in the Appwrite 1.9.0 installer, which makes the announcement immediately actionable rather than aspirational.
Why this matters
This is a notable infrastructure move because backend platforms usually promise developer simplicity by hiding architectural choice. Appwrite is moving in a different direction: keep the developer-facing layer consistent while widening the range of underlying data engines. That matters for teams that care about deployment constraints, data locality, operational familiarity, or long-term platform portability.
An inference from Appwrite’s materials is that the company wants database choice to become part of its competitive identity. The roadmap language points beyond a single MongoDB integration toward a more schema-flexible, cloud-native backend platform where the database is not a fixed design decision. For open-source backend tooling, that is a meaningful shift because it treats the persistence layer as something developers should be able to align with their existing stack instead of being forced into a single vendor opinion.
Source links: Eldad Fux X post, Appwrite announcement blog, Appwrite self-hosting guide.
Related Articles
On April 9, 2026, PyTorch said on X that Safetensors and Helion have joined the PyTorch Foundation as foundation-hosted projects. The move gives the foundation a stronger role in model distribution safety and low-level kernel tooling across the open-source AI stack.
Astral’s April 8, 2026 post became an HN talking point because it turned supply-chain security into concrete CI/CD practice. The key pieces were banning risky GitHub Actions triggers, hash-pinning actions, shrinking permissions, isolating secrets, and using GitHub Apps or Trusted Publishing where Actions defaults fall short.
A Hacker News discussion is focusing on a new Linux kernel document that permits AI assistance but keeps DCO, GPL-2.0-only compatibility, and final accountability with human submitters.
Comments (0)
No comments yet. Be the first to comment!