iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
A small production schema can work when the product’s rules are small and stable. In a case study published October 6, 2026, developer Daniel Pertu describes a desktop app whose production database has one licenses table, ten columns, four unique constraints and no foreign keys. His explanation is that selling permanent licenses and a one-time upgrade avoids the time-dependent entitlement state that recurring subscriptions would require.
What the one-table schema contains
Pertu’s DEV Community post describes the schema as 33 lines and reports that it had not been touched for 71 days, despite 23 subsequent repository commits. These are the author’s figures at publication, not independently audited measurements. The table is presented as the production schema for the app’s license and upgrade entitlements, rather than as a general template for all applications.
The ten columns cover license identity and token data; a Stripe checkout session ID; whether the license is active; whether the auto-reply upgrade was purchased; the upgrade checkout session ID and purchase timestamp; and created and updated timestamps. Pertu says the table has four unique constraints and no foreign keys. The post does not provide enough information to infer the exact constraint definitions beyond the author’s discussion of retry-safe writes and token collisions.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsWhy the purchase model shapes the data
The app is described as having two one-time purchases: a £20 base license and a £20 auto-reply upgrade. Pertu says there is no recurring billing; the amounts and offer details are those reported in the October 6, 2026 post and are not verified as current prices.
#1 Best Overall
One-time entitlements
In this design, a customer’s upgrade entitlement can be represented by a boolean: the upgrade has been purchased or it has not. The author says it is granted when the payment webhook receives checkout.session.completed. The autoReplyPurchasedAt timestamp is retained for support and accounting, but the post says no entitlement check reads it.
What subscriptions would add
Pertu’s central design argument is that a subscription entitlement is time-dependent. The system would need to account for subscription status and a billing-period end, decide what to do during a grace window, and process subscription and invoice webhook events. Those states and transitions are absent from the described one-time-purchase model because access does not expire at a renewal boundary.
This is a fit between the schema and this product’s described rules, not evidence that subscriptions are inherently a poor choice. The post does not describe renewals, seats, usage meters, plan tiers or server-side customer settings. A product that needs any of those may require additional entities, fields or event handling.
How the author handles integrity and license lookup
Pertu presents unique constraints as storage-level safeguards: they help make writes safe to retry and prevent token collisions. The post also describes license lookup as returning one null outcome when credentials are missing, mismatched or the license is inactive. According to the author, collapsing those cases avoids telling a caller which credential detail was wrong.
That lookup behavior is a privacy-oriented choice in the application’s interface; it does not mean every database query should conceal useful distinctions from authorized operators. The post does not specify the complete authentication, logging or support workflow, so those details should not be inferred from the single null result.
Webhook retries and operational choices
The webhook handler described in the post ignores event types other than checkout.session.completed. Pertu notes that if the activation email fails, the handler returns HTTP 500 so Stripe can retry. That retry behavior makes idempotency important: a repeated completion event must not create duplicate or conflicting license state. The unique constraints are one part of the author’s approach, but the post does not establish that constraints alone guarantee idempotency for every side effect, such as sending email.
Rank #3
For its serverless connection setup with Supabase/PgBouncer transaction pooling, Pertu reports setting prepare: false and a local pool maximum of one. The author attributes prepared-statement errors to transaction-mode pooling reusing backend connections and says the small local pool matches instances handling one request at a time. These are implementation details reported for that setup, not universal recommendations; driver and provider behavior can vary.
What the schema’s change history does—and does not—show
The post reports two migrations: the initial seven-column table, followed by a migration adding three columns and one constraint. It says the schema had gone 71 days without a change while the repository accumulated 23 commits. That history suggests the schema did not need to change for those reported code changes; it does not show that the schema will remain sufficient as the product evolves.
One example of a product rule influencing structure is the author’s decision not to add a free-license path. Pertu says the existing assumption is that every license row originates from a Stripe purchase. Supporting free licenses would challenge that assumption and could require a different way to represent how a license was issued. The schema therefore reflects a business rule, not merely a preference for fewer lines.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.When this approach is a useful model
The case study is most useful as a reminder to model the entitlement lifecycle the product actually has. A compact table can be reasonable when each license has a clear purchase origin, upgrades are permanent, and the system does not need renewal or metering logic. It is not a target to copy by counting tables or lines.
- Start with the product’s entitlement rules: whether access expires, renews, varies by plan, or depends on usage.
- Represent real lifecycle transitions explicitly, including payment completion, retry handling and any time boundary that changes access.
- Use database constraints to protect invariants that must hold even when application requests are retried or concurrent.
- Revisit assumptions when the business model changes, such as adding free licenses, subscriptions, seats or customer-managed settings.
Daniel Pertu summarizes the value of documenting a deliberate absence this way: “Writing down that nothing reads a column is worth the line.”
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
