Vendure vs EverShop: Framework Depth or Faster Full-Stack Start?

Both platforms are open source, run on Node.js, and speak GraphQL — but they solve different jobs. Vendure Core 3.7.1 is a headless framework you build a storefront on top of; EverShop 2.1.2 is a single deployable app with a storefront, admin panel and API already wired together. This article is written against those two versions: Node.js v20, v22 or v24 for Vendure, and Node.js 20.x+ with PostgreSQL 13+ for EverShop.

Vendure is a headless framework; EverShop ships a complete storefront

Vendure Core 3.7.1 ships three deployable pieces: a Server exposing separate Shop and Admin GraphQL APIs, a Worker that runs background jobs such as search indexing and email sending, and a Dashboard for admin tasks. None of that includes a customer-facing storefront — Vendure’s architecture overview (opens in a new tab) treats the storefront as a separate concern from the backend it documents.

To put a shop in front of a customer, you assemble one yourself. Vendure publishes an official Next.js storefront starter, available from v3.5.2, and the community maintains Remix and Qwik alternatives — see Storefront Starters (opens in a new tab). That’s a second codebase, a second deploy pipeline, and a second set of dependencies to keep in step with the Shop API.

EverShop 2.1.2 takes the opposite approach. One npm package boots a server-rendered React storefront with client-side hydration, a React admin panel, and the API both talk to, all against a single required database. There’s no separate frontend repository to scaffold or version alongside the backend.

graph TD
    subgraph Vendure["Vendure Core 3.7.1"]
        VS["Server: Shop API + Admin API"] --> VW["Worker: background jobs"]
        VS --> VD["Dashboard: admin UI"]
        VS -. assembled separately .-> VF["Storefront: Next.js / Remix / Qwik"]
        VS --> VDB[("PostgreSQL / MySQL / SQLite")]
    end
    subgraph EverShop["EverShop 2.1.2"]
        ES["Single app: storefront + admin + API"] --> EDB[("PostgreSQL 13+")]
    end

Database support tracks the same split. Vendure runs on PostgreSQL, MySQL/MariaDB or SQLite through TypeORM, so the backend’s database choice doesn’t have to match anything else in your stack. EverShop requires PostgreSQL specifically, with no other engine supported.

The trade is explicit: Vendure spends your setup time buying architectural control over every layer. EverShop spends some of that control buying a working app on day one.

Compare the license terms: Vendure’s GPLv3 core vs EverShop’s GPL-3.0

Vendure Core has been licensed under GPLv3 since Vendure v3, released 17 July 2024, per the project’s CHANGELOG (opens in a new tab). Before that, versions through 2.3 shipped under MIT — Vendure’s license change announcement (opens in a new tab) explains why, and older comparison posts that still call Vendure “MIT-licensed” are describing a version two major releases behind.

For teams that can’t accept GPL’s copyleft and source-disclosure terms, Vendure sells a separate proprietary Vendure Commercial License (VCL) as an opt-out — see Vendure Pricing (opens in a new tab). EverShop 2.1.2, released 2026-04-03 per its GitHub releases (opens in a new tab), has no equivalent. Its entire codebase — storefront, admin panel and API — ships under GPL-3.0 with no commercial core license, as confirmed in the EverShop repository (opens in a new tab).

That distinction matters if you plan to distribute a modified core as part of a product: GPL’s copyleft terms can require releasing your changes under the same license. Vendure sells a paid way out of that obligation; EverShop doesn’t offer one.

Confirm both packages’ declared license and version fields directly, rather than trusting a cached comparison post:

npm view @vendure/core version license
npm view evershop version license

Expected output:

3.7.1
GPL-3.0-or-later
2.1.2
GPL-3.0

The first two lines are @vendure/core; the next two are evershop.

You should now see: GPL-3.0 (or GPL-3.0-or-later) printed for both packages, confirming neither is MIT despite what older comparison articles claim.

What ships free and what costs extra on each platform

Vendure’s GPLv3 core is free, but its B2B tooling isn’t. Companies, approval workflows, quotes and contract pricing are gated behind the paid Vendure Platform tier, priced as a flat annual subscription starting at €40,000 with no GMV, order or user fees — see Vendure Pricing (opens in a new tab). Everything outside that bundle — catalogue, checkout, promotions, both GraphQL APIs, plugins — ships in the free core.

EverShop doesn’t split its feature set that way. Its single GPL-3.0 tier covers the entire documented feature set, and there’s no paid “core” upgrade holding functionality back from the free version.

graph LR
    subgraph VendureFree["Vendure - free, GPLv3 core"]
        VC["Catalogue, checkout, promotions, Shop API, Admin API, plugins"]
    end
    subgraph VendurePaid["Vendure Platform - paid, from EUR 40,000/yr"]
        VP["Companies, approvals, quotes, contract pricing"]
    end
    subgraph EverShopFree["EverShop - free, GPL-3.0, entire app"]
        EF["Storefront, admin panel, API, catalogue, checkout, promotions, Stripe/PayPal/COD"]
    end

EverShop does sell hosting: EverShop Cloud lists a Personal plan at $10/month and a Professional plan at $20/month, but both are still marked “Coming Soon” as of this article’s July 2026 check — see EverShop Pricing (opens in a new tab). Vendure Cloud, its managed-hosting equivalent, is mentioned on the same pricing page without published self-serve rates, separate from the quote-based Platform subscription.

“Open source” doesn’t mean “every feature is free” for Vendure — the core is free, and the parts marketed as B2B tooling are a separate purchase. For EverShop’s current feature set, open source and free line up exactly, because nothing is held back behind a second tier.

Vendure’s admin UI is mid-transition; EverShop’s is one settled panel

Vendure’s original Admin UI, built on Angular, stops receiving maintenance after July 2026 — the same month this article was researched. It’s being replaced by a React-based Dashboard, which started as an alpha release alongside Vendure v3.2 and is now the recommended admin interface — see Announcing our new Admin UI (opens in a new tab).

That transition has a direct cost for anyone who has already customised the Angular UI. Custom list pages, custom field inputs and widgets built against Angular stop getting vendor bug fixes once it’s unmaintained, even though the extension keeps running for now. Migrating from Admin UI (opens in a new tab) documents the move, and Vendure says both UIs can run side by side during the transition.

EverShop doesn’t have this problem, because it has never had two admin UIs to choose between. It ships one React-based admin panel, with no legacy interface to plan a migration off.

If you’re starting a new Vendure project today, build extensions against the Dashboard, not the Angular Admin UI. That holds even where older tutorials and forum answers still reference the Angular API, since following them now means building on a UI that’s about to stop receiving fixes.

Compare the GraphQL API architecture: split Shop/Admin vs one merged schema

Vendure exposes two independently extensible GraphQL APIs: a public Shop API (opens in a new tab) scoped to storefront operations — products, carts, checkout, customer accounts — and a separately scoped Admin API for backend operations. A plugin can add a field or query to just the Shop API, just the Admin API, or both, and the two schemas are served and secured independently.

EverShop merges type definitions and resolvers from every module — catalogue, checkout, promotions, CMS — into one GraphQL schema, documented in EverShop’s GraphQL system (opens in a new tab). Admin panel and storefront code share that single schema rather than talking to separate APIs.

graph TD
    subgraph V["Vendure - two schemas"]
        VSA["Shop API - public, storefront-scoped"]
        VAA["Admin API - private, backend-scoped"]
    end
    subgraph E["EverShop - one schema"]
        EAPI["Merged GraphQL schema - storefront and admin fields together"]
    end

The practical difference shows up when you decide what’s public. Vendure’s separation makes it straightforward to expose only the Shop API to the internet and keep the Admin API behind authentication and a private network boundary, because they’re already two different endpoints. EverShop’s merged schema needs deliberate field-level authorization, since a storefront client and an admin client query the same schema through the same door.

Neither approach is wrong, but they ask for different discipline: Vendure asks you to maintain two schemas, EverShop asks you to police one.

Check B2B and multi-vendor readiness before you commit

Vendure’s multi-tenant primitive is Channels — a way to partition catalogue, inventory and orders across storefronts or sub-brands from one install. Combined with custom roles and permissions, Channels can be assembled into a multi-vendor marketplace, as Multi-tenant Commerce with Vendure (opens in a new tab) describes. That’s custom implementation work on top of a primitive, not a turnkey marketplace feature you switch on.

Vendure’s B2B tooling — companies, approval workflows, quotes, contract pricing, documented at B2B ecommerce platform (opens in a new tab) — ships only in the paid Platform tier described above, not in the free GPLv3 core. Budget for that subscription before assuming a Vendure build covers B2B account structures.

EverShop’s documented core modules cover catalogue, checkout, customer accounts, orders, promotions, CMS and tax, with Stripe, PayPal and Cash-on-Delivery payment integrations built in. As of v2.1.2, no multi-vendor or B2B account/approval module appears in that documented core — that’s a medium-confidence read of the current docs and changelog, and it’s worth re-checking before it drives a build decision.

Neither platform ships a marketplace out of the box. Vendure offers paid B2B primitives plus do-it-yourself multi-vendor via Channels; EverShop offers neither, and a vendor-payout or seller-onboarding requirement would mean custom module work on EverShop’s events and subscribers (opens in a new tab) system.

Match install requirements: Node, npm and database versions for each platform

Vendure officially supports Node.js v20, v22 and v24, with PostgreSQL, MySQL/MariaDB or SQLite as the database, connected through TypeORM — see Installing Vendure (opens in a new tab). EverShop requires Node.js 20.x or higher, npm 9.x or higher, and PostgreSQL 13 or higher (15+ recommended), with no MySQL or SQLite option, per EverShop System Requirements (opens in a new tab).

The known failure mode is quiet. npx create-evershop-app completes without error, but the app fails to boot with a database connection error or a syntax error the first time you start it, because the local Node, npm or PostgreSQL version was too old for what the installer assumed. The scaffolding step doesn’t check your toolchain against the stated minimums before it writes files.

Check your local versions against both platforms’ minimums before running either installer:

node -v
npm -v
psql --version

Vendure needs Node v20, v22 or v24. EverShop needs Node 20.x+, npm 9.x+, and PostgreSQL 13+ (15+ recommended) — and only PostgreSQL, since it has no MySQL or SQLite fallback. The actual version strings printed depend on what’s installed on your machine, so there’s no fixed output to show here — just confirm each one clears the relevant threshold before you scaffold.

You should now see: three version strings that each clear the relevant platform’s stated minimum, confirmed before you scaffold either project rather than after a failed boot.

Use this decision framework: comparison table plus best-for and avoid-when

Both platforms answer to different requirements. Line them up against the same facts before choosing:

Vendure best for: a custom or headless storefront — mobile app, multiple brands or channels, a non-web frontend; teams that can budget for B2B or Platform-tier features; teams comfortable maintaining a separate storefront codebase alongside the backend.

Vendure avoid when: you want a working storefront on day one with no separate frontend build, or you can’t justify €40,000/year for B2B tooling.

EverShop best for: one deployable app — storefront, admin and API together, no separate frontend project; a PostgreSQL-only stack; wanting every feature under one free license.

EverShop avoid when: you need MySQL or SQLite, you need a documented multi-vendor or B2B approval workflow, or you need a headless-only architecture for a non-web client.

flowchart TD
    A["Need a working storefront with no separate frontend build?"] -->|Yes| B["Need MySQL/SQLite or a non-web client?"]
    A -->|No| C["Building headless or a non-web storefront?"]
    B -->|Yes| D["Neither fits cleanly - re-check requirements"]
    B -->|No| E["EverShop"]
    C -->|Yes| F["Can you budget Platform tier for B2B?"]
    C -->|No| E
    F -->|Yes, need B2B| G["Vendure + Platform tier"]
    F -->|No B2B needed| H["Vendure core, GPLv3"]

You should now see: a filled comparison table and a best-for/avoid-when checklist to bring into a team decision, not a feature-parity list that treats both platforms as interchangeable.

What this comparison did not test

This comparison didn’t benchmark request latency, cold-start time or throughput for either platform under load — treat any performance claim you find elsewhere as unverified until you measure it on your own infrastructure. It also didn’t include an actual multi-vendor build on Vendure Channels, or a production EverShop deployment at real scale.

Exact command output for create-evershop-app or Vendure’s project scaffolding wasn’t captured against the specific versions this article covers, so don’t expect your terminal to match anything beyond what’s shown above. EverShop’s core module list in the B2B and multi-vendor section is a medium-confidence read of current docs and is worth re-checking against the v2.1.2 changelog before it drives a build decision.

Run both platforms’ quickstarts against a throwaway project before committing either one to production.