Database support without a clear default
Too many starter kits list multiple engines but do not tell buyers which path is actually production-ready.
Stack / Database Integration
A database integration layer built for product change, not just first-run schema setup
BunShip uses Postgres and Drizzle to keep schema, migrations, and shared typed access aligned across app modules, billing logic, and AI workflows.
- Postgres + Drizzle as the primary path
- Migration and seed workflow already documented
- Typed data access across modules
- Supports auth, billing, and AI product state
Typed
Data access
Drizzle keeps schema and query behavior closer together.
1
Primary DB path
One strong database integration story is better than many thin adapter pages.
Shared
Package model
Database logic can be reused across the workspace instead of scattered per route.
This page should explain database strategy at the system level and avoid fragmenting into low-value engine-specific pages too early.
This page should explain database strategy at the system level and avoid fragmenting into low-value engine-specific pages too early.
Schema ownershipMigrationsSeedsTyped queries
What this page solves
Technical buyers want to know whether the data layer is coherent, not whether the starter can name-drop many databases.
Schema logic spread across the app
Without a strong data-layer strategy, auth, billing, and AI modules become harder to evolve safely.
Migrations are treated as an afterthought
Buyers need confidence that schema changes and deploy workflows are already considered.
What's included
Keep the database story centered on the implemented path that BunShip already uses in production-minded flows.
Drizzle schema and migration model
Schema ownership and migrations are part of the product foundation.
Shared typed access layer
Database behavior can be reused across modules instead of copied into feature code.
Seed and environment workflow
Bootstrapping and environment-specific setup are already part of the repository story.
Why it matters
This page should build technical trust and reduce ambiguity around how BunShip stores critical product state.
Supports safer product changes
Auth, billing, and AI modules can evolve against a clearer data contract.
Reduces implementation ambiguity
A buyer can see the primary stack path instead of guessing among many half-supported options.
Fits production workflows
Schema changes, seeds, and deployment concerns are treated as part of the system design.
Implementation notes
Use docs to carry the deeper implementation details and keep this page architecture-focused.
Database docs
Read the BunShip database implementation and deployment notes.
/docs/features/database
Operations deployment docs
See how database concerns fit production deployment and environment config.
/docs/operations/deployment
Billing feature page
Return to a commercial feature that relies directly on the data layer.
/features/billing
Who it's for
This page is best for technical evaluators and teams planning long-lived products.
Engineering leads
Evaluate whether the schema and query model can support product growth.
Founders with compliance concerns
Understand where critical customer, billing, and usage data lives.
Agency teams
Use one strong default database path instead of inventing a new data layer per client.
FAQ
Use this page to prevent database messaging from fragmenting into premature support matrices.
Next step
Use the database page to establish technical confidence, then continue into docs or commercial modules
Open the database docs or continue to billing, where the data layer becomes a user-facing business flow.