BigCommerce vs Saleor: which to choose

BigCommerce vs Saleor: when each option fits

BigCommerce fits best when you want a hosted store run by the vendor, your team is small, and nobody wants to operate servers, databases or background workers. Catalog, checkout, hosting and platform upgrades sit with BigCommerce, and your in-house effort goes into merchandising, content and the integrations you need. The trade-off is that your API calls, storefront options and data model stay within what the platform exposes and what your plan allows. If your main goal is a fast launch with limited engineering capacity, a hosted platform usually matches that goal better than a self-run stack.

Saleor fits when integration is API-first, you sell through several channels with different prices and stock, or you must keep data in infrastructure you control. Everything is exposed through a GraphQL API, and channel-specific pricing, currencies, stock and products are part of the core model, so a B2B storefront, a marketplace feed and a consumer site can run from one backend. It also suits data residency requirements, because you choose where PostgreSQL, the API and workers run. The price of that control is an engineering team that can own Python, Django, Celery and PostgreSQL in production, along with the storefront you build on top. Before committing, confirm your required regions, hosting provider and support model with the vendors and your own security team.

The decision turns on three things: team capacity, hosting control and the storefront you will build. Ask who will patch, scale, back up and monitor the platform after launch, and whether that person or team exists today. Decide whether data location and operational access must be controlled by you or can be delegated to a SaaS provider. Then estimate the storefront effort, since Saleor provides the commerce backend but not a finished customer-facing site. If the answers point to a small team and no appetite for infrastructure, BigCommerce is the lower-risk path. If they point to a capable engineering group and strict control requirements, Saleor deserves a proof of concept against your real catalog before you decide.

Which scenarios favor BigCommerce and which favor Saleor

This table matches common buyer situations to the platform that fits them better and the condition that makes the advantage matter. Read each row against your own team, regions and existing services, because the same feature can count for a lot in one case and very little in another. The main takeaway is that Saleor's advantages depend on channels, a Python team and in-house hosting capacity, while BigCommerce's advantages depend on a hosted store run by a small team.

Scenario	Better fit	Why it matters and when it applies
Single-region retailer with a small team	BigCommerce	A hosted store removes the need to run servers, databases, workers and upgrades. This holds when no one on the team is assigned to platform operations.
Multi-country brand selling in several currencies through channels	Saleor	Saleor supports per-channel pricing, currencies, stock and products across multiple warehouses. The advantage applies when channel-level pricing and stock rules are central to the business model.
Strict data residency rules	Saleor	Self-hosting lets you choose where Saleor, PostgreSQL and order data are stored. Confirm with BigCommerce which hosting regions and data processing terms apply to your data before deciding.
Team already running Python and Django services	Saleor	Saleor is built on Python, Django, GraphQL and PostgreSQL, so existing skills and monitoring tools carry over. The advantage applies when those engineers can own the platform after launch.
Headless storefront built by an in-house frontend team	Saleor	Saleor exposes everything through a GraphQL API, so storefront teams can work against one schema. This matters most when the storefront is a custom build rather than a theme.
Merchant who wants a managed uptime commitment	BigCommerce	A SaaS platform carries hosting, patching and infrastructure operations under its own terms. Ask BigCommerce for its current uptime commitment in writing before comparing it with self-hosting.
Team without capacity to run Celery workers and caches	BigCommerce	Saleor needs the API, Dashboard, PostgreSQL, Valkey or Redis, and Celery workers running and monitored. If that operating load is not planned, a hosted platform reduces the risk of unmanaged downtime.
Extensions and promotions handled by a partner app marketplace	BigCommerce	BigCommerce apps can cover many merchant needs without custom code. If your plan relies on prebuilt apps, check that Saleor webhooks and apps can cover the same workflows before migrating.

What you build for the storefront on each side

Catalyst is BigCommerce's headless storefront, published under the MIT license and built on Next.js. Your team keeps the storefront code and can change its pages and components, but every product, price, cart and order call still goes to a BigCommerce account. The storefront is portable as code, while the commerce data and the rules behind checkout stay in the BigCommerce platform. Catalyst does not remove the platform dependency, so the storefront work and the platform contract are separate costs.

Checkout flows: Checkout logic, payment steps and tax display follow BigCommerce's checkout behavior, so custom flows must fit the features the platform exposes.
Search: Product search and filtering use the search capabilities of the BigCommerce account, and changes to relevance or faceting depend on what the platform allows.
Content: Landing pages and editorial content are built inside the storefront code or the BigCommerce admin, so confirm who edits what day to day.
Deployment: You host the Next.js front end on your own or a third-party host, but the BigCommerce account, API limits and uptime remain under the vendor's control.
Ongoing work: Framework upgrades and Catalyst releases are yours to apply.

Before deciding, confirm with BigCommerce which Catalyst version and API features your plan supports.

Capabilities, licensing and hosting compared

This table sets BigCommerce's supplied API and catalog coverage against Saleor's channel, stock, payment and promotion capabilities, then compares licensing and hosting. Where the depth of a capability is not documented in our sources, the cell tells you what to confirm with the vendor before you decide.

Capability	BigCommerce	Saleor
Product and variant data	Catalog API manages products, categories, brands, variants, images, custom fields and metafields	GraphQL API exposes products and products across channels; confirm how variants map to Saleor attributes for your catalog
Bulk pricing rules	Catalog API includes bulk pricing rules as a managed object	Per-channel pricing is supported; confirm how volume-based rules would be modeled in your setup
Custom fields and metafields	Supported through the Catalog API	Extended through metadata and API extensions; confirm the mapping for your existing fields
Multi-channel and currencies	Confirm channel and currency handling for your storefront count with BigCommerce	Per-channel pricing, currencies and stock are supported across channels
Stock across warehouses	Confirm multi-location inventory support on your BigCommerce plan	Stock is supported across multiple warehouses
Split payments and multi-gateway	Confirm split payment and gateway options with BigCommerce	Split payments and multi-gateway payment support are included
Returns and fulfillment	Confirm returns handling in your plan and apps	Returns and multi-warehouse fulfillment are included
Promotions	Confirm promotion types such as cart rules and coupons against your plan	Promotion engine covers sales, vouchers, cart rules and gift cards
Extension model	Apps from the BigCommerce app marketplace	Webhooks, apps, metadata and API extensions, not in-process plugins
Licensing	Hosted SaaS service under a BigCommerce subscription	BSD-3-Clause open source; you run the software
Hosting	BigCommerce hosts the store and its infrastructure	Saleor Cloud managed hosting, or self-hosted with Docker

Running Python, Django, PostgreSQL and Celery yourself

A self-hosted Saleor store is several services, not one application. Each component below has a different owner for upgrades, backups, monitoring and patching, and the split of that work decides how much your team carries after go-live.

The Saleor API

The API is the Python and Django service that exposes everything through GraphQL, so it sits on the path of every storefront request, webhook and app. Your team owns its upgrades, its environment configuration and the decision to track each Saleor release. Check how often you plan to take releases, since the project publishes new versions on its releases page, and who tests custom apps against each one. Effort rises with the number of custom apps, webhooks and API extensions you write.

The Saleor Dashboard

The Dashboard is the staff interface for products, orders, channels and promotions, and it is deployed separately from the API. Your team owns its build, hosting and access control, including who can change prices or stock in each channel. Confirm how your staff accounts, permissions and any single sign-on will be set up before cutover, because merchandising errors in a multi-channel catalog are hard to spot. Effort rises with the number of staff roles and any custom Dashboard changes.

PostgreSQL as the system of record

PostgreSQL holds products, channel prices, stock levels, orders and customer records, so it is the component that carries the most data risk. Your database team or hosting provider owns backups, point-in-time recovery, restore testing, major version upgrades and patching. Ask for tested restore times, not only backup schedules, and confirm who receives the database alerts. Effort rises with order volume, the number of channels and warehouses, and how strict your recovery targets are.

Valkey or Redis and Celery workers

Saleor needs Valkey or Redis alongside Celery workers for background jobs such as webhooks, asynchronous tasks and scheduled work. A stalled queue can delay order processing and stock updates without any visible error on the storefront, so monitoring queue depth and worker health matters more than the cache itself. Your team owns the worker scaling, Redis memory limits and the restart policy. Effort rises with the volume of webhooks and integrations, and with how many promotion or stock jobs run at peak times.

Memory and sizing for production

The Docker Compose setup asks for at least 5 GB of memory for Docker, which is a development baseline and not a production sizing figure. Production sizing depends on catalog size, traffic peaks, the number of channels and the worker count. Ask your implementation partner for a sizing plan based on a load test against your own catalog, and confirm the hosting cost for the API, Dashboard, database, cache and workers as separate line items. Effort rises with traffic spikes such as seasonal promotions.

Environment variables and 12-factor configuration

Saleor is configured through environment variables that follow 12-factor app principles, so secrets, database URLs, storage settings and payment gateway keys live outside the code. Your team owns the secret store, the deployment pipeline that injects these values, and rotation of credentials. Check that payment and webhook secrets are not committed to repositories and that each environment, such as staging and production, has its own values. Effort rises with the number of environments and integrated services.

Where your data sits and who controls it

The hosting model decides who operates the servers, who holds the keys and which compliance evidence you must produce yourself. The cards below cover the decisions that differ between BigCommerce's hosted service, Saleor Cloud and a self-hosted Saleor deployment in your own cloud or data center.

Data location and hosting model

BigCommerce runs the store on its hosted service, so you rely on its regions and contractual terms for where customer and order records sit. Saleor Cloud is managed hosting, while self-hosted Saleor lets you choose the region, the data center and the network boundary. Ask BigCommerce and Saleor Cloud in writing which regions hold your data, where backups go and which sub-processors touch it. For self-hosting, the location is whatever your own infrastructure provides.

Who operates the platform

On BigCommerce, the provider patches the platform, runs the database and maintains uptime. With self-hosted Saleor, your team or your implementation partner operates the API, the Dashboard, PostgreSQL, the cache layer and the Celery workers. Write down who patches each component, who responds to incidents and who restores backups, because these duties move to you when you leave a SaaS platform.

Identity and admin access

BigCommerce admin accounts and API credentials are managed inside its platform, with its own role model. Saleor's Dashboard and GraphQL API use staff accounts, permissions and app tokens that you define, and self-hosted deployments can connect staff login to your existing identity provider. Plan how you will issue, rotate and revoke API tokens for storefronts, integrations and the migration itself, and confirm which administrative actions the provider can take on your behalf.

Secrets and configuration

Saleor is configured through environment variables, which means database credentials, signing keys and payment gateway secrets live in your deployment configuration rather than in a vendor console. Decide where these values are stored, how they reach the containers and who can read them. Your secrets manager, not a shared file, should hold them, and access to production configuration should be logged.

Payment card data and PCI DSS scope

Scope depends on how cards are captured. Hosted checkout or tokenized payment fields keep card numbers out of your servers, which reduces scope, while custom checkout code that handles card data widens it. Saleor supports multiple payment gateways, so confirm with your payment providers and your assessor which integration method applies and which parts of the stack fall inside the PCI DSS assessment. DeployOpen prepares systems and evidence for the assessment, but it does not issue audit reports or certifications.

Audit evidence and assessor review

Whichever model you choose, an assessor will ask for logs, access reviews, change records and backup test results. On BigCommerce, part of that evidence comes from the provider's own attestations, which you should request. On self-hosted Saleor, you must generate and retain it yourself. DeployOpen can help set up the controls and collect the evidence, but independent auditors and certification bodies decide whether the controls meet the standard.

What a self-run Saleor store costs beyond licences

The Saleor licence is free under BSD-3-Clause, so the comparison with BigCommerce is about who pays for what. On the BigCommerce side, you pay a subscription and any app fees, and BigCommerce runs hosting, uptime and platform upgrades. On the Saleor side, the software costs nothing to license, but you pay for the infrastructure and people who run the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, plus the storefront you build and host yourself. Ask each vendor or partner to split its quote along those lines so the two totals can be compared line by line.

One-time costs are the migration, the storefront build and the integrations. Migration covers pulling the catalog through the Catalog API within your plan's rate limits, mapping variants, custom fields and metafields to Saleor attributes, and setting up channels for each currency and price list. The storefront is usually the largest single item because Saleor has no built-in theme layer, so you need a storefront built on its GraphQL API. Payment gateways and search services also need integration work. A written scope with named deliverables, such as a mapped attribute list, a tested import of orders and customers, and a signed-off storefront, is the most reliable way to keep this block from growing.

Recurring costs are hosting, operations, upgrades, monitoring and support. Hosting depends on the memory you allocate (the Saleor Docker Compose setup asks for at least 5 GB of memory for Docker, which is a development baseline, not a production sizing), the number of API and worker instances, and whether you run PostgreSQL and Valkey or Redis as managed services. Other recurring items include monitoring, backups, security patching for Python and Django dependencies, and the staff time to apply Saleor releases such as the 3.23.42 release published on October 16, 2026. Ask any implementation partner for the support hours, response commitments and the upgrade method included in a retainer, and confirm whether Saleor Cloud is a cheaper option for the hosting layer in your region.

How a move from BigCommerce to Saleor is structured

The sequence turns a BigCommerce store into a tested Saleor backend and storefront, with the live store kept as a fallback until the new one is verified. Each step ends with a check that tells the team whether to move on.

Confirm scope and the decision basis
Leadership, the commerce owner and the engineering lead agree on what must move: products, variants, customers, order history, content, promotions and integrations. They also list the BigCommerce apps in use and the features that must match, such as multi-currency pricing, B2B rules and multi-storefront needs. This is the point to confirm that Saleor's channels, promotion engine and GraphQL API cover those needs and to note any gaps that will need custom work. The step is done when the scope is written down and signed off, with each gap assigned an owner.
Extract the catalog through the Catalog API
The engineering team pulls products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields through the BigCommerce Catalog API. Requests run within the rate limits of the store's plan, so the extraction script needs batching, retries and resumable checkpoints. Images are downloaded or their public URLs recorded, because a CSV export does not carry them. The step is done when record counts in the raw extract match the store's admin counts for each object type, and a sample of products has been checked field by field.
Map variants, metafields and channels to Saleor
Architects and the merchandising team map BigCommerce fields to Saleor's model. Product types and attributes take the place of custom fields and metafields, variants map to Saleor variants, and per-currency or per-region prices map to channels with their own pricing, currencies and stock across warehouses. Bulk pricing rules need a decision about whether they become Saleor price lists, promotions or custom logic. The output is a written mapping document with one row per source field and a named target, plus a list of fields that need a decision. The step closes when that document is reviewed and approved.
Import catalog, customers and orders into Saleor
The data team loads the mapped catalog into a staging Saleor instance through its GraphQL API, then imports customers and historical orders. Customer records need a review for personal data handling and for how account passwords are treated, since credentials usually cannot be moved between platforms. Orders are imported as read-only history so that support staff can answer questions after cutover. The step is done when a reconciliation report shows matching product, customer and order totals, and any rejected records are logged with a reason.
Rebuild the storefront against the Saleor API
The front-end team builds or adapts a storefront that reads products, channels, prices, cart and checkout from Saleor's GraphQL API. Theme, templates, checkout flows and any BigCommerce app functions are rebuilt as Saleor apps, webhooks or storefront code, since Saleor extends through webhooks, apps and metadata rather than in-process plugins. Payment gateways, tax and shipping are connected and tested in the staging environment. The step is done when a full test order can be placed in each channel and the storefront matches the agreed design and feature list.
Map SEO URLs and set up redirects
The SEO lead compares the live BigCommerce URLs for products, categories, brands and content pages against the URL structure in the new storefront. Every old URL that changes gets a permanent redirect rule, and the rules are tested before go-live. Sitemaps, canonical tags and structured data are checked in staging. Search Console or equivalent monitoring is prepared so that crawl errors can be spotted quickly. The step is done when a complete list of old-to-new URL pairs has been crawled in staging with no unexpected 404 responses.
Run parallel tests and verify content
QA and the business team run parallel tests on the staging stack, covering search, filtering, checkout, refunds, returns, promotions, gift cards and multi-warehouse fulfillment. Content, product images and any media are confirmed in the new store, because the original store should stay live until images and content have been imported and checked from their public URLs. Performance and error monitoring are checked under realistic test load, and runbooks are written for the operations team. The step is done when the test log shows every critical journey passing and the content checklist is complete.
Cut over and keep the fallback in place
The team agrees a cutover window, freezes catalog and order changes on BigCommerce for the final sync, runs the last delta import into Saleor, updates DNS or routing, and switches the storefront to the production Saleor instance. The BigCommerce store stays available as a fallback for a period agreed in advance, with monitoring on orders and redirects. The step is done when the first live orders are reconciled in Saleor, the redirect error rate is within the agreed threshold, and the fallback decommission date is recorded in the runbook.

Questions buyers ask before choosing Saleor over BigCommerce

How much effort does moving from BigCommerce to Saleor take?

The effort depends mostly on how much of your store is custom. Moving catalog data through the Catalog API is usually the easier part, because it covers products, categories, brands, variants, images, custom fields and metafields. The harder parts are rebuilding the storefront, which you do not get from BigCommerce's theme system, and replacing any BigCommerce apps with Saleor webhooks, apps and metadata. Stores with many channels, multi-currency pricing, or custom checkout logic add work for each channel and rule you need to model.

How long does the switch take, and what changes the timeline?

No fixed duration applies to every store, so ask for one tied to a written scope. The main drivers are the number of products and variants, how many channels and currencies you sell in, how many integrations (ERP, payments, shipping, tax, email) must be rewired, and how much of the storefront is rebuilt rather than reused. Data quality also matters: inconsistent attributes or missing images slow the import. Your team's availability for reviews and sign-off often determines the calendar more than the technical work.

What does the work need from our team?

Plan for product, merchandising and finance staff to confirm how catalog data, pricing per channel and tax rules should map to Saleor, and for engineers to own the storefront, integrations and hosting. You will also need someone accountable for the cutover decision, including SEO redirects and customer communication. Ask the partner which decisions they need from you in writing, and when, before the work starts.

Can an in-house team run the migration without outside help?

Yes, if the team already operates Python, Django and PostgreSQL services and has someone who can build a GraphQL storefront. Saleor's documentation describes running the API, the Dashboard, PostgreSQL, Valkey or Redis, and Celery workers, so the team must be comfortable with that stack. Teams without this experience usually bring in outside help for the first cutover and then keep operations in-house. Be honest about the skills gap before committing to a schedule.

What does running Saleor involve after launch?

Running Saleor is recurring work. You own hosting, database backups, patching of Python dependencies and the operating system, monitoring of API and worker queues, payment gateway updates, and the upgrade path to each new Saleor release. Your monthly cost is the infrastructure plus the people who keep it running, not a subscription fee. Confirm with the partner whether upgrades, security testing and on-call support are included or offered as a retainer.

Can we keep BigCommerce's Catalyst storefront?

Catalyst is an MIT-licensed Next.js storefront, but it is built to run against a BigCommerce account, so it does not work with Saleor as is. If you want to keep the storefront code, you will need to rewrite its data layer against Saleor's GraphQL API, which is a different schema. Your existing components, styles and routing may carry over, while the data fetching and cart logic usually need rework. Ask the partner to review that split before estimating the storefront effort.

What should we ask a partner for in a fixed-scope quote?

Ask for a written scope that lists each data set to migrate, the channels and currencies in use, each integration to rebuild, the storefront pages in scope, the testing and cutover steps, and the handover documentation. Request the deliverables, the assumptions behind each one, the dependencies on your team, and what is excluded. Ask how SEO redirects and customer data exports will be verified, and how post-launch support is priced if you want it. A quote should follow from that written scope, and DeployOpen prepares it on that basis.

How do the cost components of running Saleor compare with BigCommerce fees?

BigCommerce charges recurring plan fees, while Saleor is free under BSD-3-Clause, so your costs shift to one-time implementation and recurring hosting and staffing. The recurring items to model are the application servers, Celery workers, PostgreSQL, Valkey or Redis, backups, payment and search services, and the people who operate them. The one-time items are the migration, storefront build and integrations. Ask for each item separately so you can compare the totals against your current invoices.

How DeployOpen helps you evaluate, implement or migrate

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a BigCommerce to Saleor decision, we start by agreeing on what the store must do across channels, currencies and warehouses, then build and hand over a Saleor deployment that your team can run.

How we scope

Inventory which BigCommerce features your storefront, channels and integrations depend on today.
Map channel-specific pricing, currencies, warehouses and promotions to the Saleor model before any build starts.
Agree deliverables, timelines and responsibilities in a written, fixed-scope document before work begins.

How we build

Set up Saleor with its API, Dashboard, PostgreSQL, Valkey or Redis and Celery workers in your infrastructure.
Design extensions through webhooks, apps and metadata, and document which BigCommerce apps they replace.
Run security testing of the API, storefront and integrations before the store takes live traffic.

How we hand over

Deliver runbooks for deployment, environment variables, upgrades, backups and database restores.
Document the Catalog API extraction, data mapping and any evidence needed for your compliance assessment.
Train your platform, operations and development staff on running and changing the Saleor environment.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live.
Plan Saleor version upgrades with your team, including testing the storefront against the GraphQL API changes.
Coordinate with your independent auditors when they assess controls, since DeployOpen prepares evidence but does not issue audit reports.

BigCommerce vs Saleor