database_skill

This skill helps you design multi-tenant database schemas, choose a suitable platform, and implement secure, scalable data patterns for SaaS.

144

GitHub Stars

1

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill whawkinsiv/solo-founder-superpowers --skill database

  • SKILL.md8.1 KB

Overview

This skill helps non-technical founders choose databases, design multi-tenant schemas, set up Supabase or equivalent, write queries, and fix data issues. It focuses on simple, secure patterns for SaaS: organization-based multi-tenancy, Row Level Security, migrations, and practical performance tips. The guidance favors pragmatic defaults so you can ship quickly and safely.

How this skill works

I inspect your product’s core objects and recommend a minimal schema that maps users to organizations and ties all customer data to an org_id. I generate SQL for tables, indexes, RLS policies, and migrations, and point out where to add soft deletes, audit logs, and common constraints. I also review queries and offer simple performance improvements and testing steps for migrations and RLS.

When to use it

  • You’re building a SaaS and need a secure multi-tenant schema.
  • You need a migration written for Supabase/Postgres or RLS policies added.
  • You must fix data leaks or enforce org-level isolation.
  • You want simple performance fixes for slow queries or missing indexes.
  • You’re deciding whether to use Supabase/Postgres or another hosted DB.

Best practices

  • Use the database provided by your hosting platform (Supabase/Postgres by default).
  • Design schema with org_id on every customer table and index it.
  • Enable Row Level Security on all customer-facing tables and write SELECT/INSERT/UPDATE policies tied to memberships.
  • Never change production schema directly—use versioned migrations and test on a branch DB first.
  • Start simple: avoid Redis/Elasticsearch/data warehouses until you have measurable needs.

Example use cases

  • Create users, organizations, and memberships tables with proper constraints and timestamps.
  • Add a core business table (projects, invoices) linked to org_id with indexes and RLS policies.
  • Write a Supabase migration to add a status column plus updated RLS policy adjustments.
  • Audit and fix an RLS misconfiguration that allows cross-org reads.
  • Optimize a slow query by adding indexes and switching to cursor-based pagination.

FAQ

Yes for SaaS: RLS is the reliable way to guarantee org-level isolation. Treat it as mandatory on customer data tables.

Which database should I pick as a solo founder?

Use the default your platform integrates with—Supabase (Postgres) is the recommended default for most early SaaS apps.

How do I handle deletions?

Use soft deletes (deleted_at) and update RLS to exclude deleted rows. Hard deletes are risky for audit and recovery.

Built by
VeilStrat
AI signals for GTM teams
© 2026 VeilStrat. All rights reserved.All systems operational