Query Dojo Review: Browser SQL Feedback, Write Queries, and Free Practice Limits

Query Dojo gives you a practical next step after SELECT: changing rows that must commit together. Its public inventory-transfer exercise checked the resulting table and explained why an uncommitted transaction failed. In our browser test, the same two updates failed without COMMIT and passed after we added it. That is a useful, specific demonstration of write-query feedback.

Before trying the runner, use PracHub’s database-transactions question to explain what must happen to both inventory rows. A successful statement and a committed business operation are different events. Query Dojo’s exercise makes that distinction visible, although it does not establish every guarantee needed for a production transfer service.

Checked November 3, 2026: official descriptions, our anonymous browser actions, and an original local SQLite exercise are identified separately. We did not subscribe through the iPhone app, purchase web access, or validate timed-mock scoring. No independent candidate-outcome evidence establishes hiring effectiveness. PracHub publishes this review and provides the linked preparation questions.

The public write challenge we actually ran

The Query Dojo homepage linked to The Atomic Stock Transfer. The public task asked us to move 50 units from product 1 to product 3 and commit the transaction. Its instructions described a private database copy discarded after every run.

The starting stock values included 500 units for product 1 and 200 for product 3. Product 2 had 300 and product 4 had 150. We used the same two update statements in both attempts, changing only whether the transaction was committed.

BEGIN;
UPDATE product_inventory
SET current_stock = current_stock - 50
WHERE product_id = 1;
UPDATE product_inventory
SET current_stock = current_stock + 50
WHERE product_id = 3;
COMMIT;

Without the final statement, the runner displayed a failure and explicitly said the transaction had never committed, so everything was rolled back. The after-table retained the original stock values. Adding COMMIT produced a solved message and the expected table: 450 for product 1, 250 for product 3, with the other two products unchanged.

This negative control matters because both statements can look plausible in an editor. The failure was about the transaction’s completion, not misspelled SQL. The explanation connected the unchanged table to the missing commit, which gives a learner a concrete next repair.

The observation is limited to this exercise and its checker. We did not inspect the engine implementation, create competing writers, or test a connection loss between commit and acknowledgment. The page’s private-copy statement is an official runtime description, not our audit of database isolation.

Browser practice and Premium are different access paths

The homepage advertised lessons, four SQLite databases, table previews and a mixture of free and Premium challenges. Catalog totals differed across pages during our check: the homepage displayed 95 challenges and 44 free, while the Premium page described 85 challenges with 51 Premium. We would not use either changing total as a quality score.

Premium’s purchase action was “Subscribe in app.” The page said web subscriptions were coming soon and that one subscription would eventually unlock access everywhere. It displayed $7.95 monthly and $49.95 yearly pricing. These are observed offer descriptions, not purchases or cross-platform entitlements we verified.

Timed mocks and readiness scores were also advertised. We did not complete a timed mock, assess whether its questions resemble a particular employer’s assessment, or establish how its numerical readiness output is calibrated. A score on a preparation product cannot be assumed to represent an employer’s cutoff.

If you want browser-only practice today, open the exact free task you need before planning around a subscription. If you already use the iPhone app, verify the active account and what carries into the browser. The presence of an annual price does not by itself establish that the web checkout is available or that a specific mock is unlocked there.

For this review, the meaningful free-access finding is simple: we could edit and run the public stock-transfer challenge without creating an account. Account saving, app subscriptions, paid mock results and synchronization remain outside the verified scope.

What a final-table check does not establish

Matching the expected inventory table is a useful test, but it answers a narrower question than “is this a safe transfer service?” A single run can finish correctly while a repeated request moves the stock twice. It can also omit checks for negative stock, invalid products, inconsistent request identity or concurrent transfers.

Suppose a client sends a transfer, the server commits it, and the response disappears. The client cannot infer from the timeout that nothing happened. Retrying the two updates with a new attempt identifier could perform the movement again. Transaction atomicity alone does not identify repeated business work.

This is an editorial extension of the observed task, not a claim that Query Dojo promises a production transfer API or that its exercise is defective. The original problem can reasonably test the specified table transformation. Your interview explanation should still state which assumptions make that transformation sufficient.

A good answer distinguishes three states: no transaction committed, a transaction committed and acknowledged, and a transaction whose result is unknown to the caller. The first may be retried as new work under the appropriate contract. The last requires reconciliation or reuse of the same logical operation identity.

An original repeated-transfer fixture

We built a separate local SQLite fixture with two stock rows containing 120 and 80 units. The requested movement was 25 units from the first to the second, identified by logical key move-17. This is our example, not Query Dojo’s dataset or hidden checker.

The fixture first attempted to insert that key into a unique movement ledger. It performed the stock updates only when the insert created a new record. Both the ledger write and inventory changes belonged to the same transaction. Sending the identical request twice produced stock values of 95 and 105 after both attempts.

The total remained 200. That invariant catches a missing credit or debit, while the unchanged second result catches repeated application. Either property alone would be incomplete: moving 25 twice preserves the total but violates the intended operation count.

The fixture used one SQLite connection and fixed valid inputs. It did not prove multiwriter isolation or sufficient-stock enforcement. In a real implementation, the operation key must also be associated with request fields. Reusing move-17 for a different amount should be a conflict, not an accidental success.

Do not copy INSERT OR IGNORE into another database without checking dialect and error semantics. The operation record and its effect must commit together. The exact SQL and locking strategy must fit the database and the invariants you promise.

How to use the feedback without learning the wrong lesson

Begin with a prediction of the complete after-table. Include unchanged rows, not just the two rows you intend to edit. An overly broad WHERE clause can move the target rows correctly while modifying unrelated inventory. Comparing only the headline quantities would miss that error.

Next, introduce one deliberate defect. In our native test, omitting COMMIT gave an interpretable failure. Another educational mutation is updating the wrong destination identifier. Keep the task’s database-reset behavior in mind: a fresh private copy can prevent previous attempts from affecting the next run, but that also means it is not a demonstration of durable multi-session state.

Read the first mismatch before rewriting the query. A wrong row count suggests a different investigation from a correct row count with wrong values. A commit explanation points toward transaction lifecycle. A syntax error points toward parsing or dialect. These categories help you choose the smallest useful repair.

After a pass, close the solution and explain the operation to someone else. State when the change becomes durable, what a failure before commit should leave behind, and why a timeout after commit is ambiguous. If you cannot answer the last question, a replay fixture is a better next exercise than another simple update.

For a timed screen, rehearse the environment separately from the SQL reasoning. Confirm the supported dialect, whether write statements are allowed, how a run resets data, and whether your submission needs a final query or a changed table. Those details can change a valid solution without changing the business objective.

Five follow-up questions for the gaps this exposes

The following PracHub questions extend the transaction and write-safety discussion. They are independent practice records, not Query Dojo content or predictions about a company’s assessment.

The in-memory transaction problem removes SQL syntax and asks you to make begin, commit and rollback semantics explicit. The ledger question adds repeated work and balanced effects. Hotel booking changes the business invariant to competing reservations. Transaction analytics returns to reading data, where an apparently correct result can still hide a wrong aggregation grain.

Choose one extension rather than treating the list as a completion target. If commits are confusing, explain a rollback trace. If retries are confusing, run the same logical request twice. If you understand both, add a second writer and specify the outcome you expect before selecting a concurrency mechanism.

Who is Query Dojo a good fit for?

Its public write challenge is a useful fit for learners who can already read basic SQL but need feedback on transaction completion and resulting state. Our missing-commit control produced a relevant explanation, and the corrected query produced the intended table. That is a stronger reason to try it than the size of its advertised library.

It is a less certain choice when your immediate requirement is verified browser Premium access, a particular timed mock, or an independently validated readiness score. The purchase path we inspected pointed to the app. We did not test paid or cross-device behavior, so those should remain questions you resolve before committing preparation time.

Use the stock-transfer task to establish the first layer, then write an original replay case that tests operation identity. For further rehearsal, select a transaction or correctness question from PracHub’s Data Engineer questions and explain the exact failure your chosen mechanism prevents. Keep the SQL result and the business guarantee in the same explanation.

Sources and further reading

• Query Dojo homepage and public practice descriptions
• The Atomic Stock Transfer: public write exercise
• Query Dojo Premium: displayed prices and app subscription path
• Query Dojo privacy policy