Compare
Shapio vs Payload
Payload is code-first and lives inside a Next.js app. Shapio is data-first and runs beside any site.
Side by side
| Area | Shapio | Payload |
|---|---|---|
| Where the model lives | Shapio Versioned rows in the database, edited live from the admin or applied from JSON files. | Payload TypeScript config files in the repository; every change is a code change and a deploy. |
| Changing a type in production | Shapio Live, no restart. | Payload Edit the config and deploy; the admin never changes the model. |
| Schema in git | Shapio Yes. | Payload Yes, as TypeScript config; every change is a deploy. |
| Hosting shape | Shapio A server (npm or Docker) plus any front end: Astro, Next, SvelteKit or anything that fetches JSON. | Payload Inside your Next.js app (or standalone through Express); the admin ships with the app. |
| Type safety | Shapio TypeScript types and OpenAPI generated from the live schema ( | Payload Types generated from the config at build time. |
| Multi-site | Shapio Sites with their own schema, and shared types. | Payload The multi-tenant plugin. |
| Localization | Shapio Per field: a field is localized or shared. Fallback chains (fr-CA, then fr, then the default) in the API, which says which locale served each entry. A shared value changed in one locale lands in every locale's draft, and the admin offers to publish the other locales in one action. Any BCP 47 code. Delivery, GraphQL, SEO defaults and visual editing all know the locale. | Payload Field-level localization with fallbacks; publishing is per document. |
| Roles and permissions | Shapio Custom admin roles per content type, field and action, per site; end-user accounts with Google and GitHub sign-in; an audit log. All in the open-source build. | Payload Access control functions in code, very flexible. |
| Rich text | Shapio Tiptap JSON, HTML on request. | Payload Lexical JSON. |
| Databases | Shapio PostgreSQL, MySQL, SQLite. | Payload MongoDB, PostgreSQL, SQLite. |
| Visual editing | Shapio Draft preview beside the document and click-to-edit on the page, per site, from a snapshot you can pin. | Payload Live preview in the admin. |
| Pricing | Shapio Apache-2.0, every feature, self-hosted. No paid tier yet; a hosted cloud is planned. | Payload MIT, every feature; Payload Cloud is the hosted option. |
Measured
| Request | Shapio | Payload |
|---|---|---|
| List of 20 with a populated relation | Shapio 2,296 req/s, 51.5 KB, 5 SQL statements 2.7 ms per request | Payload 1,435 req/s, 60.7 KB, 3 SQL statements 2.3 ms per request |
| One entry by slug, with populate | Shapio 6,554 req/s, 2.7 KB, 5 SQL statements 1.7 ms per request | Payload 3,001 req/s, 3.2 KB, 3 SQL statements 1.5 ms per request |
| Filtered list | Shapio 2,750 req/s, 39.7 KB, 3 SQL statements 2.7 ms per request | Payload 2,115 req/s, 49.6 KB, 2 SQL statements 2.1 ms per request |
Note: Payload's API runs inside the Next.js process, so a single request is 0.2–0.6 ms quicker on every row; Shapio serves 1.3–2.2x the traffic on all three. | ||
req/s: requests answered per second with ten readers at once, on the same machine. ms: how long one request took on its own, median of three rounds. Lower ms and higher req/s are better.
Same seeded data, same machine, PostgreSQL 18, autocannon with 10 connections, medians of three rounds. Shapio 0.4.1 against Payload 3.90. Both at default settings with logging on. Harness and raw results are published with the release; numbers move with versions and hardware, so run it yourself.
Why switch
And when not to.
Payload is a fine choice if your site is Next.js, your team is happy changing the model in TypeScript, and every change can go through a deploy. Its in-process API is quicker per request, and we say so above. Shapio is for everyone that description leaves out: editors who need a new field today, agencies running several sites on one instance, front ends in Astro, SvelteKit or anything that fetches JSON, and teams that want the schema versioned, reviewable and shipped with the content instead of baked into a build. Same feature set, no deploy to change the model, and it serves more traffic on all three requests we measured. If the model is code to you, keep Payload. If the model belongs to the people editing the content, switch.