Appwrite launches managed native PostgreSQL and MySQL alongside its document databases

What Appwrite shipped

Appwrite now offers managed native PostgreSQL and MySQL, a significant expansion beyond the document-style data products the platform was built around. According to a September 11 announcement on dev.to by Jake, an engineer on Appwrite's database team, the service provisions an actual database engine in your project's region, complete with its own hostname, credentials and TLS — not a SQL interface layered over the company's existing storage.

That distinction is central to the launch. Appwrite's TablesDB, DocumentsDB and VectorsDB are managed data products reached through SDKs, permissions and the platform layer. The new databases are the engines themselves: nothing Appwrite-specific sits between the application and its data, so any standard client or ORM can connect directly.

Versions and connection layout

Setup happens in the Appwrite Console: pick PostgreSQL or MySQL, pick a compute tier, and the engine is provisioned. PostgreSQL defaults to version 18, with 17 selectable at creation; MySQL defaults to 8.4, with 8.0 as an option.

Each database serves a single hostname on two ports. PostgreSQL exposes a connection pooler on 6432 and direct connections on 5432, while MySQL uses 6033 for the pooler and 3306 for direct access. The author recommends routing normal runtime traffic through the pooler and reserving the direct port for migrations, dumps and anything that depends on session semantics — an arrangement he describes as the dependable pattern for serverless workloads, where large numbers of short-lived connections are the norm.

Direct access means conventional tooling just works: psql and the mysql command-line client, plus frameworks such as Prisma, Drizzle, TypeORM, Kysely, Knex and Sequelize. Guides for Prisma, Drizzle and raw drivers are already in the documentation, while integration guides for the remaining ORMs were still being published at announcement time.

What the platform handles

Appwrite takes on the operational layer: backups with point-in-time recovery, high availability with up to five replicas and automatic failover, online resizing between tiers, IP allowlists, monitoring, and a SQL editor inside the Console. Each database gets its own pooler, which can split reads and writes once replicas are switched on.

A branching capability creates preview databases from storage snapshots, so teams can stand up isolated copies without manually duplicating anything. On PostgreSQL, extensions including PostGIS, pgvector and pg_trgm are available — a response, the author writes, to developers who have long asked for genuine Postgres so they can run their own migrations and use vector search. Appwrite has also published a launch post and product documentation on its site, and the author shared a short provisioning and connection demo on video.

Pricing and availability

The starter tier costs $10 per month and includes 1 vCPU, 1 GB of memory and 10 GB of storage. Pro plans bundle $10 per month in database credits, so the starter tier adds no extra cost for existing Pro subscribers. Rollout is regional, starting with Frankfurt and New York; because a database is deployed in the same region as its project, the author suggests creating projects in one of those regions to try the service now.

Why it matters

Backend platforms have typically asked developers to either accept proprietary data APIs or run relational databases elsewhere and wire them in manually. Managed native engines remove that trade-off: existing schemas, migrations and ORM code carry over largely unchanged, and capabilities like pgvector and PostGIS become usable alongside the rest of the platform's services. The credit-backed pricing also makes experimentation essentially free for current Pro users.

The caveats are the usual ones for a launch announcement. Every operational detail — failover behaviour, recovery guarantees, pooling semantics — comes from the Appwrite engineer who built much of the feature and has not been independently tested here, and parts of the documentation were still landing when the post went up. Teams with session-heavy workloads will want to probe how the pooler-versus-direct-port split behaves under their own load before committing.