Home / Product / Database choices

Own your data foundation

Run the same application model on the database that fits your deployment.

Choose SQLite for fitting single-instance uses or connect MySQL or PostgreSQL when the product needs a separately operated relational database.

See what it changes Technical guide ↗

Database choices in a product

Choose the operating shapeLocal evaluation, single server, or external database

Connect the supported engineSQLite, MySQL, or PostgreSQL

Keep the product contractRecords and capabilities use the same model

Infrastructure choice does not redefine the product

01Start at the right sizeUse SQLite where simplicity matters and its concurrency fits.

02Bring an established databaseOperate MySQL or PostgreSQL with your existing practices.

03Keep application meaning portableRetain one model and public record contract across supported engines.

Why it matters

Choosing a database should be an operating decision, not a rewrite of the product.

A local prototype benefits from an embedded database. A larger or multi-node deployment may need a separately managed relational service with its own backups, failover, and monitoring. Locking application behavior to one topology makes growth expensive.

Daptin supports SQLite, MySQL, and PostgreSQL behind the same resource model. The backend continues to understand the same records, relationships, permissions, actions, and public identities.

Operators can therefore choose the database shape that fits while product teams keep one conceptual backend. The tradeoffs remain real: concurrency, migrations, availability, and recovery belong to the chosen engine.

Match complexity to the deployment

Avoid operating a separate database when an embedded one truly fits.

Use existing organizational skills

Connect a supported engine your team already knows how to run.

Keep the application contract steady

Separate public record identity from database-internal keys.

How it fits

Part of one connected backend.

Database choices does more when it can reuse the records, people, access rules, and workflows already in your application.

Step 1Choose

Select the supported database for the deployment.

Step 2Configure

Provide connection and pool settings appropriate to the engine.

Step 3Model

Apply the same application records and relationships.

Step 4Operate

Back up, observe, migrate, and recover the chosen system.

What it enables

Use it in products people recognize.

Start from the experience you want to create; the backend capability supports the work behind it.

Local product evaluation

Start one Daptin instance with SQLite and persistent storage.

Team application

Use PostgreSQL or MySQL under established operational ownership.

Multi-node runtime

Share a separately operated database across application nodes.

Connected by design

Build the next part without starting over.

These capabilities share the same application context, so each one makes database choices more useful.

Know the boundary

What Daptin leaves in your hands.

Supported engines do not have identical concurrency or operational characteristics. SQLite is intentionally connection-constrained; external databases require correct pooling, backups, network security, migration planning, and capacity management.

Understand the operating responsibility →

Build from one foundation

Make database choices part of the product—not another disconnected service.

Run Daptin locally, explore the live administration surface, and follow one complete application path.

Get Daptin Explore all capabilities