PostgreSQL vs NoSQL: A Reproducible 10,000-Order Marketplace Benchmark

A marketplace receives 10,000 checkout intentions, but that number says nothing about database capacity until the arrival window, transaction boundaries and correctness checks are defined. Ten thousand orders spread across a day and the same count concentrated into a promotion create different engineering problems. This article is a hypothetical, reproducible test protocol, not a report of measured throughput or client results. No production benchmark was run for this guide.

The useful purchasing question is not whether SQL beats NoSQL. It is whether a specific implementation can preserve inventory and financial rules while meeting an agreed response-time budget, recovery objective and operating cost. PostgreSQL is one named database; NoSQL is a broad category. Here, MongoDB is the document-database candidate used to make the comparison concrete. Neither candidate earns a performance claim without an executed, disclosed experiment.

Use this protocol to commission evidence before choosing the transaction store for a multi-vendor marketplace. It covers the workload contract, data model, contention, external payments, failure injection and final decision record. The output should be a reviewable evidence package, not a winner badge attached to an unexplained transactions-per-second number.

First define what counts as one order

Write a checkout intention as a durable business identifier. A customer submits an intention containing cart contents, delivery choice, price version and an idempotency key. That intention may produce a rejected request, a temporary reservation or an accepted order. It may also produce several HTTP requests when the network fails. Count those separately.

For the proposed experiment, generate exactly 10,000 unique intentions. Give each a deterministic identifier and record the random seed. Then generate a separate retry stream referencing selected identifiers. The retry requests increase offered traffic but do not increase the number of unique intended orders. This distinction exposes implementations that appear productive because they count duplicate creations as successful throughput.

Define the accepted-order boundary before instrumentation. One possible definition is an order record, reserved inventory, seller allocation and outbox event committed together. Payment authorization may remain an external, asynchronous step. Another architecture might authorize first and confirm later. Both can be evaluated, but they answer different questions and need different compensation tests.

Keep three clocks: request receipt to response, intention creation to durable acceptance, and acceptance to terminal payment outcome. A fast acknowledgment should not conceal a queue that never drains. Declare whether an HTTP success means accepted, pending or completed, and make the load generator interpret it accordingly. A pending response is not a confirmed sale.

Freeze a configuration manifest, not a database label

Record exact server and driver versions, deployment topology, operating system, CPU allocation, memory limits, disk type, network placement and connection-pool settings. Export relevant runtime configuration with secrets removed. Include index definitions and migrations. A reviewer must be able to identify the candidate that produced each result without relying on a screenshot caption.

For PostgreSQL, disclose the chosen isolation level, synchronous-commit behavior, replication arrangements, connection pooling and transaction timeout policy. For MongoDB, disclose replica-set or sharded topology, read preference, transaction read concern, write concern and driver session behavior. A standalone document database without an equivalent multi-record transaction path is not an interchangeable candidate for this experiment.

Do not quietly compare a durable acknowledgment with a weaker acknowledgment and call the difference an engine advantage. The settings need not have identical names; they must satisfy the same declared business promise. Document remaining semantic differences explicitly. Replication is also not a backup: include an independent restoration procedure in the operating assessment.

Store the manifest beside the workload definition and a code revision identifier. Freeze it after a non-scored rehearsal. Later tuning creates a new candidate rather than rewriting the identity of a completed run. This preserves the difference between diagnosing a bottleneck and selectively presenting the best result from an unknown number of attempts.

Model the same business rules in different shapes

A relational candidate might use orders, order lines, reservations, payment attempts, seller allocations and outbox records. A document candidate might embed immutable order lines and allocation details in an order aggregate while keeping shared inventory separately. Equivalent outcomes do not require identical schemas. Forcing either engine into an unsuitable shape would test the artificial schema more than the product architecture.

The difficult boundary is shared state. Two orders can compete for the same last item even when each order fits comfortably in one document. An atomic update to one order document does not automatically coordinate a separate inventory document. The MongoDB transaction documentation describes both single-document atomicity and multi-document transactions; the application must select the appropriate boundary rather than infer correctness from the database category.

Write invariants in domain language. Active reservations plus confirmed consumption must not exceed available stock after legitimate replenishment and adjustment events. One checkout intention must not create two accepted orders. Seller allocations must reconcile to the order's defined financial components. A reversal must reference an eligible original event and cannot exceed its remaining reversible amount.

Translate each invariant into executable checks over durable records. Include allowed intermediate states and their deadlines. A payment awaiting reconciliation is different from a missing payment record. The marketplace payout ledger guide provides a complementary state-model discussion; this database experiment should test those rules instead of substituting a generic insert workload.

Separate realistic traffic from deliberate stress

Build a normal shopping scenario with a declared distribution of customers, sellers, cart sizes and products. Include browsing and order-status reads if the tested application serves them through the same constrained resources. Preserve a representative history dataset: a tiny empty database can hide index and cache behavior that emerges only when older orders occupy storage.

Create a separate contention scenario concentrating demand on a small inventory pool. Label it adversarial rather than typical. Uniform random product selection spreads writes so conveniently that oversell protection may never be exercised. A deliberately scarce product forces the implementation to demonstrate what happens when several buyers compete for the same remaining unit.

Vary arrival rate independently of concurrency. In a closed-loop test, clients wait before issuing more work, which can reduce offered load as responses slow. An open-arrival schedule attempts requests at predetermined times and makes overload more visible. Whichever model is used, report intended arrivals, actual arrivals, delayed starts and abandoned requests. Do not hide generator scheduling delay inside a reassuring response percentile.

The proposed 10,000-intention count is an experimental batch size, not an industry benchmark or guaranteed operating limit. Choose the arrival window and burst shape from the product's forecast, then run a separate sensitivity case above that forecast. Retain the same workload seeds across candidates where possible, while alternating execution order to reduce environmental bias.

Instrument the whole waiting path

Measure client-side end-to-end response time and server-side phases separately. Trace admission waiting, application queueing, connection acquisition, transaction execution, commit acknowledgment and asynchronous completion. Without this decomposition, a slow connection pool can be mistaken for a database execution problem, or a short database query can conceal a long queue ahead of it.

Report latency distributions for successful, rejected and failed requests, with clear denominators. Include p50, p95 and p99 where the sample supports interpretation, alongside sample count and run duration. Do not combine a cheap status read with a contested checkout into one percentile. A timeout is an outcome, not a sample to delete because it lacks a completion timestamp.

Track attempted transactions, committed intentions, transaction retries, idempotent replays and terminal failures. Measure retry amplification: how much extra database work each useful business result required. A candidate that eventually commits everything after uncontrolled retries may still be unsuitable during a sustained promotion. Bound retry attempts and their total deadline in the application contract.

Observe database CPU, memory pressure, disk latency, replication lag, locks or transaction conflicts, and connection utilization. For PostgreSQL query diagnosis, use the official EXPLAIN guidance and record the dataset and statistics state. Inspection is not permission to run expensive analysis against a live marketplace; reproduce the issue in the isolated test environment.

Test transaction conflicts instead of arguing about ACID

PostgreSQL isolation levels have different permitted behaviors, and serializable execution can require application retries. MongoDB also supports transactions; transaction guarantees depend on configuration and operations. Neither “ACID” nor “document database” is a sufficient acceptance criterion. State the anomaly the business cannot tolerate, then test whether the complete implementation prevents it.

Construct a last-item race in which multiple requests observe availability before attempting reservation. Check that exactly the permitted number succeeds and every loser receives a defined outcome. Repeat with different sellers and overlapping carts so a transaction can contend on several records. This exercises lock ordering, abort handling and recovery rather than only one convenient hot key.

Add a cross-record rule, such as a seller allocation limit enforced against current committed obligations. Verify that concurrent decisions cannot both spend the same remaining capacity. Depending on design, the implementation might use conditional updates, explicit locking, serializable transactions or another documented coordination mechanism. Score the observed invariant and operational cost, not the elegance of the mechanism's name.

Keep retry callbacks free of irreversible external side effects. A callback executed again after a transaction conflict must not initiate another charge or notification blindly. Persist an intention or outbox record and let an idempotent external workflow handle it. Record whether the driver retried automatically and which errors required application-level intervention; otherwise the results cannot explain hidden work.

Treat payments as a second system

Do not put real payment instructions into a benchmark. Use a deterministic payment simulator in an isolated environment, with configurable delays, duplicate notifications, out-of-order notifications and ambiguous timeouts. A database commit cannot atomically guarantee what an independent payment provider did. This boundary needs its own state machine and reconciliation evidence.

Give each external instruction a stable business key and preserve its relationship to the checkout intention. Simulate the response disappearing after a successful authorization. The application should recover the known instruction, inspect provider evidence or reconcile later; creating a new instruction on every timeout makes a fast database irrelevant to financial safety.

Separate authorization, capture, cancellation and refund events where the proposed product uses them. A refund request racing a capture notification should resolve according to explicit rules. Include partial refunds and split seller allocations only when they are in scope. Every extra state needs fixtures, checks and reporting; adding them casually produces an impressive-looking but unreviewable test plan.

After each run, reconcile simulated provider events against internal payment attempts and financial postings. Report unresolved breaks, their age and their owners. A result with an unexplained financial mismatch fails correctness even if every latency threshold passed. Explain that this validates the simulator contract, not a particular provider integration, settlement guarantee or regulatory outcome.

Inject failures at named boundaries

Begin with process interruption before transaction start, during transaction execution and after commit but before the response reaches the client. Each fault asks a different question. Before commit, rollback may be appropriate; after commit, a retried request should discover the existing result. Without correlation identifiers, these outcomes often get collapsed into an ambiguous error count.

Next interrupt the asynchronous worker after it reads an outbox event but before acknowledgment. Deliver the event again and check downstream idempotency. A message queue's redelivery policy should be part of the manifest. Do not describe an application as exactly-once merely because one component offers deduplication or one database transaction committed only once.

In a dedicated, authorized test cluster, exercise the supported failover path and network interruption scenarios. Record acknowledged writes, subsequent reads, election or recovery timing and any ambiguous client results. The MongoDB consistency documentation explains why read preference and read concern matter; the experiment must disclose them rather than treat every read as equivalent.

Restore a backup into another isolated environment and run the invariant checks there. A successful backup command is weaker evidence than a verified restoration with a documented recovery point. Never conduct destructive failure injection, storage exhaustion or load generation against the production server hosting unrelated applications. Rehearsal infrastructure and explicit test authorization are prerequisites, not optional conveniences.

Make pgbench answer the right-sized question

pgbench is useful for controlled PostgreSQL transaction experiments and supports custom transaction scripts. Its default workload is not a marketplace checkout implementation. A result from that default workload should not be relabeled as orders per second, and it cannot provide an engine-neutral comparison with MongoDB by itself.

Use an application-level driver for the cross-engine business scenario. Keep request payloads, arrival schedules, payment simulation and result interpretation consistent. Use database-specific tools afterward to explain a result: a custom pgbench workload can isolate a contested reservation transaction, while MongoDB diagnostics can help inspect the document candidate's behavior. Those are supporting experiments, not interchangeable headline scores.

Declare warm-up and measurement phases before execution. Report whether caches start cold or warm and how the history dataset was created. Reset the environment between independent repetitions using the documented procedure. Run several repetitions rather than selecting one attractive run, and retain failed runs with their reasons. Repeating until a desired winner appears is not replication.

Package logs, manifests, workload seeds, schema definitions, invariant-check outputs and raw observations. Redact customer data and credentials at collection time. A colleague should be able to reproduce the procedure without receiving a production database dump. Synthetic data must still preserve relevant relationships, value distributions and historical volume; random strings alone rarely model marketplace contention.

Turn results into an architecture decision

Create a decision sheet before reading the measurements. Treat correctness requirements as gates, then compare latency, useful throughput, recovery and operating burden among candidates that pass. A fast candidate with duplicate accepted orders does not receive a discounted score; it fails the declared business contract. Thresholds should come from the product's requirements rather than this article.

Assess implementation complexity honestly. Count the coordination code, retry policy, reconciliation jobs, monitoring and operator actions each candidate requires. A database with attractive raw performance may impose a workflow your team cannot safely maintain. Conversely, a familiar relational model may still need targeted indexing and contention management; familiarity is not evidence that scaling requires no work.

Compare total environment costs with clearly dated assumptions: compute, storage, replicas, backups, observability and expected operations effort. Avoid quoting permanent cloud prices or extrapolating a short test directly into monthly production spend. Explain which resources were saturated and whether the tested topology has a credible next scaling step without changing the business semantics.

The final recommendation should identify the workload envelope, unresolved risks and the next experiment. If both candidates pass, choose using operational fit and product needs instead of manufacturing a dramatic winner. If neither passes, revise the transaction design or capacity plan. Marketplace development discovery should make these trade-offs visible before a proposal turns one unverified database choice into a long-term commitment.

Buyer handover: evidence worth asking for

Request one concise interpretation alongside the raw evidence package. It should state what was tested, what was not tested, which candidate configurations passed, and what would invalidate the conclusion. Look for clear separation between generated order intentions, accepted orders and completed payments. A diagram of those boundaries is more useful than a dashboard screenshot without definitions.

Ask the delivery team to demonstrate a failed checkout recovering without creating another order. Then inspect an invariant-check report containing an intentionally seeded defect. A checker that always says zero proves little until it can detect a known mismatch. Require the defect to be removed and the clean run repeated before accepting the evidence.

Assign ownership for rerunning the protocol after schema changes, payment-flow changes, major engine upgrades or a material increase in expected demand. Retain a smaller regression scenario for routine development and the fuller experiment for capacity decisions. The companion marketplace performance-testing guide extends this database-centered protocol to the wider application journey.

Also ask for a result ledger listing every attempted run. Each row should include candidate revision, workload seed, execution order, completion status and any exclusion reason. If a cloud host was noisy or a generator failed, keep that row and explain why its measurements were excluded. This prevents an honest diagnostic rerun from becoming invisible selection bias in the final summary.

Require a separate limitations paragraph for functions outside the experiment. Search relevance, seller onboarding, tax calculation, live courier location and recommendation quality do not become validated because checkout storage passed. Likewise, success with synthetic payment events does not certify a real provider's webhook integration. A narrow experiment with explicit boundaries gives a buyer more dependable evidence than an expansive claim that quietly crosses into untested features.

Implementation references

Further reading: MongoDB Data Modeling.

Frequently asked questions

Does this article prove PostgreSQL is faster than MongoDB?

No. It provides a proposed experiment, not measured comparative results. No execution logs, hardware measurements or client outcomes are claimed. A defensible conclusion requires both named implementations to run the same declared business scenario, with disclosed configuration, repeated measurements and correctness checks. Database families cannot be ranked by the hypothetical order count in this title.

Does 10,000 orders mean 10,000 simultaneous buyers?

No. It means 10,000 unique checkout intentions in the proposed dataset. Concurrency depends on the arrival schedule, request duration and client behavior. Duplicate requests, browsing sessions and payment callbacks add separate work. State the arrival window and traffic mix explicitly before converting that dataset into a capacity requirement or comparing two implementations.

Can MongoDB safely support marketplace transactions?

MongoDB supports single-document atomicity and multi-document transactions. Whether a marketplace remains correct depends on its schema, transaction boundaries, consistency settings and application behavior. Shared inventory and financial obligations require deliberate coordination. The protocol tests the implementation's business invariants rather than assuming document storage is inherently unsafe or inherently sufficient.

Should every PostgreSQL transaction use serializable isolation?

Not automatically. Choose isolation and coordination according to the rules the transaction must preserve, then test concurrent behavior. Serializable execution can require retries, and retry handling must be safe. Other approaches may be suitable for particular conditional updates or locked resources. The PostgreSQL isolation documentation explains guarantees; it does not replace application-specific concurrency tests.

Can the fastest successful response be used as the sales claim?

No. Report distributions, failures, queued work and useful completed outcomes across disclosed runs. The best response hides the tail and says nothing about reconciliation. Any published claim should identify the exact configuration, tested workload and limitations. A synthetic benchmark is not evidence of an actual customer's production result or a guarantee of another deployment's performance.

Do we need sharding before launching a marketplace?

Not because of a hypothetical 10,000-order dataset alone. Establish workload, contention, data growth and operating requirements first. Sharding can alter transaction paths and recovery complexity, so it must be evaluated as a named architecture rather than a default upgrade. Choose the simplest candidate that passes the requirements and has a documented, testable growth path.

What should happen if all latency targets pass but reconciliation fails?

Reject the run for correctness and investigate the mismatch. Preserve the faulty evidence instead of repairing records silently and presenting the run as clean. Fix the underlying workflow, prove that the invariant checker detects the original defect, and rerun the frozen scenario. Financial and inventory consistency are acceptance gates, not optional adjustments to a throughput score.

Can this protocol be run against our live website?

Not safely as written. It includes high contention, duplicate instructions and deliberate failures. Use synthetic data, payment simulation and an isolated environment under an approved test scope. Production observation can inform realistic arrival patterns, but destructive fault injection and resource-saturation tests belong away from customer traffic and unrelated hosted applications.