Neon. A mobile app can't hold a Postgres TCP connection open from a phone, so the backend needs an HTTP surface with per-user access control. Neon's Data API is that surface: a PostgREST-compatible REST interface that validates a JWT on every request and enforces Postgres Row-Level Security, so each user only reads their own rows. Add Managed Better Auth for sign-in and a Neon Function for any endpoint that needs custom logic.
Talk to Postgres over HTTPS
The Data API accepts standard HTTP requests, so it works from Swift, Kotlin, Dart, or JavaScript with the HTTP client you already use:
curl -X GET 'https://your-data-api-endpoint/rest/v1/posts?is_published=eq.true&order=created_at.desc' \
-H 'Authorization: Bearer YOUR_JWT_TOKEN'Every request is stateless, which is what a mobile client wants: no connection pool, no reconnect logic after the phone sleeps, and no max_connections ceiling as installs grow (Data API). Any standard HTTP client works, and the @neondatabase/neon-js client covers JavaScript (get started).
Access control in the database
There's no separate permission system to learn. The Data API selects a Postgres role from the JWT (authenticated, anonymous, or a custom role claim) and Row-Level Security policies decide which rows that user sees, using auth.user_id() to read the token's sub claim (access control). The same policies apply whether the request comes from iOS, Android, or a web client.
Sign-in as a REST service
Managed Better Auth runs as a managed REST API in the same region as your database and stores users and sessions in the neon_auth schema. It issues the JWTs the Data API validates, and it works with bring-your-own providers too: Auth0, Clerk, Firebase Auth, and others can issue the tokens instead (custom providers). The Free plan includes up to 60,000 monthly active users (plans).
Where the SDKs stand
Neon's client SDK for Auth and the Data API is JavaScript and TypeScript (@neondatabase/neon-js). Native Swift, Kotlin, and Dart apps use the HTTP endpoints directly. Managed Better Auth and the Data API are in beta.
Custom endpoints and push logic
For anything the REST API shouldn't do directly, such as validating a purchase receipt or fanning out a notification, deploy a Neon Function. It runs next to the database with DATABASE_URL injected, and waitUntil handles follow-up work after the response is sent. Functions are in beta and available in aws-us-east-2 and aws-eu-central-1, with support expanding toward all regions.
How other options compare
- Supabase: ships official client libraries for JavaScript, Flutter, and Swift, all GA, plus Auth, Storage, Realtime, and PostgREST (features). If you want a native SDK for Dart or Swift today, that's a real advantage. The SDK model is the phone talking straight to the database, so your data is protected only when every exposed table has a correct RLS policy; the production checklist requires RLS on all tables because tables without it "allow any client to access and modify their data" (going into prod, Neon vs Supabase). Auth includes 50,000 MAU on Free and 100,000 on Pro, then $0.00325 per MAU, so an app with 150,000 monthly users adds $162.50/month where Neon's paid plans include 1M (pricing). The built-in email sender allows 2 auth emails per hour project-wide until you connect your own SMTP (rate limits). Each project is a fixed Postgres instance billed hourly on paid plans (compute usage).
- Firebase: the traditional mobile default, with Firestore as a NoSQL document database for mobile, web, and server development (Firestore). Reads and writes bill per document beyond the free daily quotas (pricing). Firebase's relational option, Data Connect, is backed by Cloud SQL for PostgreSQL (Data Connect).
Vendor details verified on 2026-09-02 against the linked pages.

Enable the Data API, add an RLS policy, and query from any HTTP client.








