Give Starter value that does not depend on sync

[datlechin]

Problem

Everything behind the Starter paywall today does the same thing: move data between machines.

Starter feature	What it actually is
iCloud Sync	multi-device
2 Mac activations	multi-device
Encrypted connection export	sharing
Environment variables in connection fields	sharing
Linked Folders	sharing

So a developer who works on one Mac, and who does not want connection metadata leaving that Mac, has nothing to buy. Free already covers every supported database, the SQL editor, the AI assistant, the MCP server, SSH tunnels, ER diagrams, EXPLAIN visualization, the server dashboard, Users & Roles, backup and restore, Vim mode, query history with full-text search, Safe Mode with Touch ID, and XLSX export, on unlimited Macs.

This came out of user feedback:

I think you need to revise your pricing strategy, like mole.fit, with a basic lifetime pricing for the individual version. This can ensure revenue from the basic version, while also adding some features for individuals. As for the professional version, honestly, no one would feel comfortable storing database account-related information on a third-party cloud for synchronization.

Two separate points in there, and only one is a product gap:

1. Lifetime pricing already exists. Starter is $24/year or $59 one time, and the app has supported it since day one (a license with no expiresAt shows as Lifetime in Settings > Account). Someone who read the pricing page closely enough to send feedback still missed it. That is a pricing page problem, not a pricing problem. Tracked as a side item below.
2. "Adding some features for individuals" is the real gap. For a user who declines sync, Starter is worth $0 at any price. Lowering the price does not sell it. Changing what is in it does.

Goal of this issue: give Starter value that a single-Mac user wants, without taking anything out of Free.

Proposed solution

Five candidates. All run entirely on the local machine, need no account and no sync, and build on layers that already exist. None of them exist in the codebase today.

Ground rule: nothing currently free moves behind the paywall. Repackaging free features as paid costs more trust than it earns revenue. Every item here is new work.

---

• 1. Schema Diff and migration SQL

  Compare the structure of two databases (local against staging, or two schemas on one server) and show the differences by table, column, index, foreign key and trigger. Then generate the SQL that brings one side to the other.

  Why it sells: people search for this by name. Redgate SQL Compare is an entire product built on it, and DataGrip charges for the same thing. It is also the clearest answer to the feedback above, because nothing leaves the machine.

  Builds on: the structure editor's introspection (columns, indexes, foreign keys, triggers, DDL), SQLStatementGenerator, and the sidebar multi-select that just landed in [Unreleased].

  Cost: the largest item here. Scope it to same-engine comparison first. Cross-engine diff (MySQL against PostgreSQL) is a trap, because the type mapping is never fully correct and it turns into a support hole.

• 2. Data Rewind: undo a save that already committed

  Before a grid save runs its UPDATE or DELETE, capture the previous values of exactly the affected rows to a local store. Let the user roll that save back after it has committed.

  Why it sells: highest emotional value in the list. Everyone has changed the wrong rows on a real database once. Undo today only works before the save (DataChangeUndoManager); after the save there is no route back.

  Builds on: DataChangeManager already knows which rows and columns changed, and SQLStatementGenerator already turns that same record into SQL.

  Cost and risk: must be scoped to the grid change-tracking path only, never to hand-written SQL in the editor. Capturing pre-images costs an extra round trip, and if another session edits the same rows in between, a rollback overwrites their work. The scope limit has to be stated in the UI. Promise more than this and the feature costs reputation instead of earning it.

• 3. Result set diff

  Run the same query against two connections, or compare any two result sets, and mark added rows, missing rows and changed cells.

  Why it sells: pairs naturally with item 1 and reuses its diff UI, so the marginal cost is low. Still useful to a single-Mac user, for example comparing a table before and after a migration.

  Builds on: TableRows and DisplayRowMapping.

  Cost: moderate, if it follows item 1.

• 4. Charts and pivot over a result set

  Turn a result into a chart or a pivot table without writing GROUP BY.

  Why it sells: immediately legible in a screenshot, which makes it the easiest of the five to market.

  Builds on: Swift Charts, which keeps it native.

  Cost and risk: moderate. The open question is what it charts. Results are already paginated at the database layer, so charting only the current page can quietly produce a wrong picture. It has to either run its own aggregate query or say plainly that it is charting the loaded page.

• 5. Query history insights

  Which queries you run most, which run slowest, and which got slower than they were last week.

  Why it sells: weakest of the five on its own, but by far the cheapest, so it is the one that can ship first while items 1 and 2 are being built.

  Builds on: QueryHistoryStorage is already SQLite with FTS5 and already records every executed query. This is mostly aggregate queries plus one screen.

  Cost: small.

---

Suggested order: ship 5 first so Starter gains something quickly, then put the real effort into 1. Hold 2 until after those, because it carries the most downside if a rollback ever goes wrong on a production database.

Packaging: sell these as one story rather than five bullets. Reposition Starter as local-first, where iCloud Sync is one option inside it rather than the whole reason to pay. That also answers the security half of the feedback in the place where people actually decide to buy.

Alternatives considered

• Lower the price. Does not help. The objection is that the paid tier contains nothing this user wants, not that it costs too much.
• Move existing free features behind the paywall. Rejected. Free being genuinely complete is a large part of why people try the app at all.
• Gate the AI assistant. Possible later, but it is a separate decision with its own tradeoffs, and it does not fix the "solo user has nothing to buy" problem in the same clean way. Worth its own issue if it comes up.

Related side items (not part of this issue)

• Give the $59 lifetime option equal weight to $24/year on the pricing page. It exists and people are missing it.
• State the sync security model on the pricing page, not only in the docs: data goes to the user's own iCloud, TablePro runs no server of its own, passwords are off by default and go through iCloud Keychain when enabled. This objection will keep arriving until the answer sits where the buying decision happens.
• Evaluate CloudKit encryptedValues for connection metadata fields. Note this is a CloudKit field type change, so it needs new fields, a Production deploy, a refreshed schema snapshot and a read path for existing records, per the invariant in CLAUDE.md.

Related database type

N/A / General