PocketBase + SvelteKit

Usually not. PocketBase's auth collections cover password sign-in, one-time email codes, dozens of OAuth2 providers such as Google and GitHub, and multi-factor sign-in, and the token they issue is what the collection API rules check. You can create more than one auth collection for different kinds of users, such as customers and staff, each with its own fields and sign-in methods. An external provider is worth adding only when you need SAML enterprise SSO or one login shared with services that do not talk to PocketBase, and then a custom hook has to map that provider's identity onto a PocketBase user.

Yes, but it changes the deployment. The default build uses SvelteKit's static adapter, so the app is plain files served by PocketBase and every data call goes from the browser to PocketBase with the user's token. For server rendering, run SvelteKit with the Node adapter as a second service, create a PocketBase client per request in a server hook, and load and save the auth state through a cookie, the pattern the PocketBase JavaScript SDK documents. You gain search-friendly pages and server-only secrets, and you take on a second process to host and more care with cookies. A middle path is to prerender public marketing pages at build time and keep the signed-in app as a single-page app.

Further than most side projects need. SQLite in WAL mode serves many concurrent reads quickly and keeps writes short, so a typical app with thousands of active users runs comfortably on a small server. What it cannot do is spread load across several machines: growth means a bigger server, not more of them. Plan two things early. Point the built-in backups at an S3-compatible bucket, and keep heavy work such as large imports out of request hooks. If the app later needs writes from several regions or a database shared by many services, a PostgreSQL-based backend is the better fit.

Both give a beginner a ready-made backend with auth, data, files, and realtime. This stack is the lean one: one free binary on a server you run, a SvelteKit single-page app, and costs close to the price of that server. Appwrite + Next.js starts on Appwrite's managed cloud with a free plan, adds functions, messaging, and several database engines, and pairs them with server-rendered Next.js pages, at the cost of more concepts and per-project pricing in production. Pick PocketBase for simplicity and full control of one server, Appwrite when you would rather not run the backend yourself or want the broader platform.

Treat every minor release as possibly breaking. Pin the version you deploy, read the changelog before upgrading, and take a backup of pb_data first, which the dashboard can do in one click. Collection changes are saved as migration files in pb_migrations, so commit them with the code and test an upgrade on a copy of the data before production. JavaScript hooks run on PocketBase's embedded runtime and can need small edits when its APIs change; a Go-extended build is recompiled against the new module version instead.