Databases
PostgreSQL by Default, and When I Don't Use It
By Vivek Jalondhara · 1 min read
Published Feb 2026 · Updated
Postgres is my starting point for relational data. Workload and operational constraints decide when to use something else.
Postgres is my default datastore because it does almost everything well: relational integrity, JSONB for flexibility, full-text search, and a rock-solid query planner. Reaching for something exotic should require justification, not the reverse.
I deviate when the workload demands it — time-series at scale, multi-tenant sharding, or document-heavy access patterns. Even then I check whether a Postgres extension solves it before adding a new system to operate.
Every database you run is an on-call burden. Fewer, well-understood systems beat a zoo of specialized stores you can't all reason about at 3 a.m.
Express tenant ownership in the data model
A CRM record has an identity within a tenant. A composite key can express that relationship directly and gives related tables a clear key to reference.
Illustrative example · SQL · Simplified for explanation
CREATE TABLE crm_records (
tenant_id uuid NOT NULL,
id uuid NOT NULL,
title text NOT NULL,
PRIMARY KEY (tenant_id, id)
);
-- Every tenant-scoped query still needs an authorized tenant filter.- Model ownership
- Enforce constraints
- Measure queries
- Add indexes for actual access patterns
Conceptual flow for the example above.
Tradeoff to keep in mind
Database constraints prevent some invalid states; they do not replace authorization. Choose the data model before choosing extensions.