starter.wiki中文

Decision map

Data

Which data model, operating model, and specialized access paths should the application adopt without conflating storage, access abstractions, retrieval, uploads, and client synchronization?

Recommendation

Start with Database

Application and platform teams choosing a system of record, managed or elastic database operation, data-access layer, specialized retrieval, object workflows, and local-first synchronization.

Open the starting decision

Scope

Use this boundary to avoid solving adjacent problems in the wrong layer.

Included

  • Primary database model and system-of-record decisions
  • Managed PostgreSQL and serverless database operating models
  • ORM and type-safe query-builder ownership
  • Key-value storage, disposable caching, lexical search, and vector retrieval
  • Durable file storage and application upload workflows
  • Application data synchronization, offline state, and local-first behavior

Excluded

  • Code execution, hosting, and infrastructure provisioning
  • Embedding-model generation and other AI model selection
  • Generic ETL, warehouse synchronization, and integration automation
  • CDN delivery and cache placement at the network edge
1

Important tools

These tools represent distinct routes inside this decision area; open the relevant Task before treating any as a default.

Decision sequence

Make the foundational ownership decisions before adding specialized capabilities.

  1. What is the source of truth and what access, consistency, durability, availability, latency, and recovery requirements must it satisfy?

    Start with the broad Database decision before selecting a managed provider, elastic operating model, or specialized access path.

    Database

  2. Does the workload require managed PostgreSQL specifically, or an elastic serverless database operating model?

    Evaluate provider responsibility, compatibility, backup and recovery, scaling range, scale-to-zero, resume behavior, connections, and workload economics separately.

    Managed PostgreSQL Serverless Databases

  3. How should application code construct, type, migrate, and execute database queries?

    Choose an ORM or type-safe query builder only after the database boundary is clear; the abstraction does not own durability, indexes, or service operation.

    ORMs & Type-Safe Query Builders

  4. Which access patterns require key-addressed storage, disposable caching, lexical search, or vector retrieval?

    Add only the specialized paths with a named workload and define whether they are authoritative, derived, or reconstructable.

    Key-Value Store Application Caching Lexical & Product Search Vector Search

  5. Does the product ingest files or require local and offline application data?

    Separate object storage from upload orchestration, and evaluate App Data Sync & Local-First only when client-local availability and synchronization are product requirements.

    File Storage File Upload Workflows Local-First App Data Sync

2345

Decision groups

Each Task owns a distinct user decision rather than a product feature label.

67891516172021

Common confusions

These boundaries prevent adjacent Tasks from collapsing into one generic shortlist.

Treating managed PostgreSQL and serverless database operation as mutually exclusive database families.
Managed PostgreSQL describes engine compatibility and delegated operations; Serverless Databases describes capacity, idle, resume, connection, and workload-economics behavior. A service may be both.
Treating every key-value product as a cache.
Key-value is an access and data model that can be durable; caching is an operational role for data that can be expired, evicted, or reconstructed.
Treating keyword search and vector similarity retrieval as one interchangeable index.
Search owns lexical parsing and ranking; Vector Search owns vector representation, similarity indexing, metadata filtering, and retrieval. Hybrid systems may combine both.
Treating object storage and the end-user upload workflow as the same product decision.
File Storage owns durable objects and lifecycle; File Uploads owns authorization, validation, transfer, retry, transformation, and ingestion.
Using generic data synchronization or CDC language for an application-local and offline data requirement.
App Data Sync & Local-First owns client-local storage, offline behavior, synchronized subsets, and write reconciliation; backend CDC emits change events and does not itself provide that application contract.
2101112131416171819

What to defer

Do not add specialized identity systems before the product has the requirement they serve.

The workload is stable enough that elastic capacity, scale-to-zero, cold resume, or branchable and distributed operating behavior will not change the database choice.

Serverless database evaluation adds product-specific capacity, connection, latency, and cost analysis that should be activated by a real operating-model requirement.

The primary database satisfies current access and latency requirements without a separate key-value, cache, lexical-search, or vector-retrieval system.

Each specialized path adds another data model, synchronization boundary, failure mode, and operational owner.

Only trusted server-side processes write objects and the product has no direct user or client upload path.

A dedicated upload workflow is unnecessary until client ingestion, validation, resumability, or transformation is required.

The application does not require useful offline behavior, client-local queryability, or synchronized local state.

Application synchronization introduces local storage, authorization, conflict, recovery, and consistency responsibilities.

202223

Related starter stacks

See how these decisions appear inside complete application starting points.

Authoritative resources

Standards and primary documentation supporting the Category boundaries.

architecture-guidanceAWS Well-Architected Framework
official-documentationPostgreSQL documentation
official-documentationAmazon RDS for PostgreSQL
official-documentationAmazon Aurora Serverless v2
official-documentationPostgreSQL Full Text Search
official-documentationPowerSync overview

Sources

Claim-level references used for this decision map.

  1. 1
    AWS Well-Architected Framework

    AWS · Accessed Official

  2. 2
    PostgreSQL documentation

    PostgreSQL Global Development Group · Accessed Official

  3. 3
    Amazon RDS for PostgreSQL

    AWS · Accessed Official

  4. 4
    Maintaining an Amazon RDS DB instance

    AWS · Accessed Official

  5. 5
    Introduction to Amazon RDS backups

    AWS · Accessed Official

  6. 6
    Using Amazon Aurora Serverless v2

    AWS · Accessed Official

  7. 7
    ServerlessV2ScalingConfiguration API

    AWS · Accessed Official

  8. 8
    Scale to zero

    Neon · Accessed Official

  9. 9
    Manage computes

    Neon · Accessed Official

  10. 10
    Prisma ORM overview

    Prisma · Accessed Official

  11. 11
    Prisma Client

    Prisma · Accessed Official

  12. 12
    Drizzle SQL Select

    Drizzle · Accessed Official

  13. 13
    Redis data types

    Redis · Accessed Official

  14. 14
    Redis persistence

    Redis · Accessed Official

  15. 15
    PostgreSQL Full Text Search

    PostgreSQL Global Development Group · Accessed Official

  16. 16
    pgvector README

    pgvector · Accessed Official

  17. 17
    Pinecone indexing overview

    Pinecone · Accessed Official

  18. 18
    Qdrant filtering

    Qdrant · Accessed Official

  19. 19
    Amazon S3 objects overview

    AWS · Accessed Official

  20. 20
    PowerSync overview

    PowerSync · Accessed Official

  21. 21
    PowerSync philosophy

    PowerSync · Accessed Official

  22. 22
    Debezium stable reference documentation

    Debezium · Accessed Official

  23. 23
    Debezium features

    Debezium · Accessed Official