Owning your data should mean more than a slogan

Draw the boundary of no-code

Table views, forms, and automations are excellent for validating a workflow, but they are not a data strategy. Orders, permissions, attachments, and audit records still need explicit fields, relationships, and lifecycles. A vendor UI can change; business facts should not be trapped in a button.

The database is a collaboration contract

For customers and invoices, a customer ID should be stable and an invoice should reference it rather than copy a name. Decide whether deleting a customer is blocked or historical data is retained. Put those rules in schema, constraints, and migrations so a tool change does not stop the team.

Teable’s public repository shows one way to make database capabilities approachable through a collaborative table product. Read its license and deployment documentation before choosing a hosting model.

CREATE TABLE invoices (
  id text PRIMARY KEY,
  customer_id text NOT NULL REFERENCES customers(id),
  issued_at timestamptz NOT NULL
);

Ownership means export and recovery

Plan regular exports, a recovery drill, and a field dictionary. An export is more than CSV: relationships, attachments, time zones, and deletion semantics must be reconstructable. Restore into a temporary environment and check row counts and key foreign keys before trusting the backup.

A migration lesson from undb

The public undb repository is archived and its current README points to Teable. That is a useful reminder that projects change while data must persist. Treat it as historical source material, not as a maintained service or a security promise.

When self-hosting is the wrong choice

A managed service may be safer when a team cannot maintain backups, upgrades, and access controls. That is not the same as surrendering ownership: require export formats, retention, deletion procedures, and an exit window in the contract.