Appwrite, the open-source backend-as-a-service (BaaS) platform that developers use to add authentication, databases, storage and server functions to their apps, has released version 2.0 — the biggest overhaul in the project's history.
The headline change is a new approach to data. Alongside the document stores that Appwrite has managed behind its own APIs for years, 2.0 now offers native PostgreSQL and MySQL databases that applications reach directly over the standard protocols — with psql, a MySQL client, a driver or a familiar ORM. Appwrite provisions and operates the instances, but no longer mediates between app and database. The architecture targets teams that want Appwrite for authentication and hosting while keeping their established SQL tooling, own migrations and existing applications for the data layer. The native databases are offered as dedicated, paid cloud services; fresh self-hosted installs now default to PostgreSQL, with MariaDB and MongoDB still supported. PostgreSQL 18 is the default version, with 17 available as an alternative; on the MySQL side, Appwrite uses 8.4 or 8.0.
Appwrite also introduces two new managed database types. DocumentsDB stores schema-free JSON documents: two documents in one collection may carry different fields, and new properties require no schema migration, while document-level permissions, queries, sorting and pagination remain available through the Appwrite SDKs. VectorsDB targets AI-powered search and retrieval: each collection has a fixed vector dimension, metadata can be attached to every entry, and similarity search runs on an HNSW index supporting cosine similarity, dot product and Euclidean distance. A built-in embeddings API can turn text into vectors without developers having to run a separate embedding service.
Storage gains an S3-compatible interface built on AWS Signature Version 4. It maps S3 operations onto existing Appwrite buckets and files, so the AWS CLI, AWS SDKs and S3-capable tools such as rclone can be pointed directly at Appwrite. The native storage API remains usable in parallel — files uploaded via S3 also appear in the console and vice versa.
For identity, Appwrite 2.0 ships an OAuth 2.1 server with OpenID Connect, turning a project into its own identity provider. External applications register as clients and can sign users in through a “Sign in with Appwrite”-style flow or access project resources with limited scopes. Supported building blocks include PKCE, token introspection and revocation, JWT access tokens, the Device Authorization Grant and dynamic client registration. A partner interface lets platform operators manage OAuth apps, redirect URLs, secrets and branding — for marketplaces where organizations install extensions that then work with delegated permissions on Appwrite resources.
The administration surface is new as well. Console IV, rebuilt on TanStack, unifies console, documentation, blog and changelog, and adds an in-browser terminal that runs the Appwrite CLI with project and session context already set, plus an “Explorer” that reads a project's OpenAPI description, generates input forms and fires API calls directly from the console. In the cloud, Appwrite adds Domains (domain registration, DNS and TLS certificates at organization level) and a Firewall that filters requests to APIs, Functions and Sites by IP address, hostname, path, HTTP method, headers, query parameters, user agent or location — with options to block, redirect, rate-limit or challenge requests, and a preview showing how many recent requests a rule would affect. Both features remain cloud-exclusive.
Under the hood, the execution substrate has been replaced by “Hyperloop B”, a coroutine model based on Swoole. A single process can serve multiple I/O-heavy requests by switching to other tasks while waiting on input and output. According to Appwrite, this notably reduces the memory footprint of realtime events: a document is encoded once per event instead of once per subscriber.
Self-hosters face the biggest transition. DocumentsDB and VectorsDB are initially disabled in self-hosted setups because they require additional database engines, and an optional embeddings component does not start by default due to its resource demands. Upgrading a self-hosted installation from the 1.9 series is a versioned process with migrations and a recommended backup; existing data remains on the previous database backend. Cloud projects, by contrast, keep running without a mandatory migration.
