SQL for structured data with relationships. NoSQL for the cases where it actually fits.
The SQL vs. NoSQL debate was more relevant when relational databases lacked JSON support. Modern Postgres with JSONB handles semi-structured data well. The cases where a NoSQL database is genuinely the better choice are narrower than the marketing suggests.
Database selection between relational (SQL) and document-based (NoSQL) databases — often misframed as a general vs. specialized decision
NoSQL databases were a genuine innovation for specific use cases: MongoDB for document-oriented data, Redis for caching, Cassandra for write-heavy time series. The over-rotation happened when developers started using MongoDB for everything because "we don't know our schema yet."
Why SQL (Postgres) is the default:
ACID transactions. Relational databases provide transaction guarantees: operations either fully complete or fully roll back. For financial data, inventory, and any operation where partial failure is unacceptable, this matters.
Referential integrity. Foreign keys enforce data consistency at the database level. Related records can't be orphaned.
Complex queries. JOINs, aggregations, window functions, CTEs — SQL's query capabilities are powerful and well-understood.
JSON support. Modern Postgres with JSONB handles flexible schema requirements. Semi-structured data doesn't require a NoSQL database.
Schema migrations. Structured schema with migrations (via Drizzle or Prisma) provides a clear history of the data model.
When NoSQL is genuinely the right choice:
Redis: Caching, session storage, rate limiting, leaderboards. An in-memory key-value store optimized for speed. Complement to Postgres, not a replacement.
Cassandra/DynamoDB: Write-heavy workloads at extreme scale (IoT sensor data, click streams, time series at millions of writes/second). Rare for most applications.
MongoDB: Document-oriented data without relationships, where schema flexibility is genuinely needed. The use cases are narrower than MongoDB's marketing suggests.
Database selection based on actual data access patterns, with Postgres as the default and NoSQL chosen when there's a genuine technical reason
Postgres for all relational data. Redis (via Upstash) for caching and session storage. NoSQL databases when the specific data model genuinely calls for it.
One honest number to start.
Fixed-scope, fixed-price. The number below is the starting point — final scope is built from your brief.
Database selection based on actual data access patterns, with Postgres as the default and NoSQL chosen when there's a genuine technical reason
Three steps, every time.
The same repeatable engagement on every project. No surprises, no mystery, no billable ambiguity.
Brief & discovery.
We send you questions, then get on a call. Output: a written scope with every step, feature, and integration listed.
Build & ship.
Fixed schedule, weekly reviews. No scope creep unless you change the scope — and if you do, we reprice it transparently.
Warranty & retainer.
30-day warranty on every launch. Most clients stay on a monthly retainer for ongoing features and maintenance.
Why Fixed-Price Matters Here
Database selection is part of the architecture proposal.
Questions, answered.
Migrating databases after launch is expensive. Get the decision right at the start. Postgres is the right default; the cases to deviate from it are specific and technical.
DynamoDB is excellent for its designed use cases (high-throughput key-value access patterns). Misused as a general-purpose database, it creates complexity with limited query capabilities. Use RDS Postgres on AWS instead of DynamoDB unless your access patterns are key-value only.
Tell Ryel about your project.
Describe what you’re building and what outcome you need. You’ll have a written, fixed-price scope within the week.