决策地图
数据：选择系统记录、访问方式与运行边界
从数据库、对象存储、检索和缓存开始，把数据形态与运维责任放在同一张决策图里。
Recommendation
大多数产品以托管 PostgreSQL 为起点，按实时、分支、向量检索或全球边缘需求再增加组件。
先选权威数据系统，再选托管形态；不要把 ORM、缓存或向量检索误当成数据库替代品。
范围
用这条边界避免在错误层级解决相邻问题。
包含
- 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
不包含
- 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
重要工具
这些工具代表此决策领域内不同路线；请先打开相关任务页面，再将任何工具视作默认。
- PostgreSQL
- Supabase
- Neon
- Cloudflare D1 （英文页面）
- MongoDB （英文页面）
- Crunchy Bridge （英文页面）
- Turso （英文页面）
- CockroachDB （英文页面）
- Prisma ORM （英文页面）
- Drizzle ORM （英文页面）
- Kysely （英文页面）
- TypeORM （英文页面）
- Upstash Redis （英文页面）
- Cloudflare Workers KV （英文页面）
- Amazon DynamoDB （英文页面）
- Redis Cloud （英文页面）
- Amazon ElastiCache （英文页面）
- Algolia （英文页面）
- Typesense （英文页面）
- Meilisearch （英文页面）
- Elasticsearch （英文页面）
- pgvector （英文页面）
- Pinecone
- Qdrant
- Weaviate （英文页面）
- Amazon S3
- Cloudflare R2
- Supabase Storage （英文页面）
- Backblaze B2 （英文页面）
- UploadThing （英文页面）
- Cloudinary （英文页面）
- Uploadcare （英文页面）
- Filestack （英文页面）
- PowerSync （英文页面）
- Electric （英文页面）
- Replicache （英文页面）
- Zero （英文页面）
决策顺序
先完成基础归属判断，再增加专门能力。
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.
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.
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.
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
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
决策分组
每个任务都对应一个独立的用户决策，而非产品功能标签。
System of record and operation
Choose the primary data model first, then evaluate PostgreSQL-specific management and serverless capacity as bounded operating-model decisions.
Application access and acceleration
Application query abstractions, key-addressed storage, and disposable caching change how code reaches or accelerates data without replacing the source-of-truth decision.
Retrieval and indexing
Lexical search and vector retrieval use different representations and ranking methods while remaining related data-access decisions.
Files and synchronized application data
Object persistence, upload ingestion, and client-local synchronization are separate workflows with explicit handoff boundaries.
常见混淆
这些边界避免相邻任务被压缩成一个泛泛的候选清单。
- 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.
暂缓引入
不要在产品真正需要之前引入专门系统。
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.
Starter Stack
查看这些决策如何出现在完整应用起始方案中。
官方资源
支撑此分类边界的标准与一手文档。
来源
此决策地图使用的主张级参考资料。
- 1AWS Well-Architected Framework
AWS · Accessed Official
- 2PostgreSQL documentation
PostgreSQL Global Development Group · Accessed Official
- 3Amazon RDS for PostgreSQL
AWS · Accessed Official
- 4Maintaining an Amazon RDS DB instance
AWS · Accessed Official
- 5Introduction to Amazon RDS backups
AWS · Accessed Official
- 6Using Amazon Aurora Serverless v2
AWS · Accessed Official
- 7ServerlessV2ScalingConfiguration API
AWS · Accessed Official
- 8Scale to zero
Neon · Accessed Official
- 9Manage computes
Neon · Accessed Official
- 10Prisma ORM overview
Prisma · Accessed Official
- 11Prisma Client
Prisma · Accessed Official
- 12Drizzle SQL Select
Drizzle · Accessed Official
- 13Redis data types
Redis · Accessed Official
- 14Redis persistence
Redis · Accessed Official
- 15PostgreSQL Full Text Search
PostgreSQL Global Development Group · Accessed Official
- 16pgvector README
pgvector · Accessed Official
- 17Pinecone indexing overview
Pinecone · Accessed Official
- 18Qdrant filtering
Qdrant · Accessed Official
- 19Amazon S3 objects overview
AWS · Accessed Official
- 20PowerSync overview
PowerSync · Accessed Official
- 21PowerSync philosophy
PowerSync · Accessed Official
- 22Debezium stable reference documentation
Debezium · Accessed Official
- 23Debezium features
Debezium · Accessed Official