PostgreSQL development
We model data on PostgreSQL — schemas, migrations, and performance treated as first-order design — the durable, relational default that sits under every product we build.
Most data is relational whether or not the database admits it, and Postgres is the one that admits it honestly: real constraints, real transactions, real joins, and a query planner that has earned three decades of trust. It has also quietly absorbed the features people once left it for — JSON where a column should be flexible, full-text search, extensions when a workload is unusual — so the cases that force a second database are rarer than they are made out to be.
We treat the schema as the foundation it is: modelled to reflect the real relationships in the domain, migrated in versioned steps that run the same everywhere, and indexed against the queries that actually run. It is where our encrypted per-tenant configuration lives, and it is the ledger under Lekha — a product whose whole job is keeping two sides of every account straight, which a relational database is exactly built to do.
What we build on PostgreSQL
-
Modelling the real relationships
Schemas that reflect how the domain actually works — the right normalisation, real foreign keys and constraints, integrity enforced by the database rather than hoped for in the app.
-
Migrations you can trust
Versioned, reversible migrations that run identically in every environment, so the schema evolves in reviewable steps instead of drifting by hand.
-
Performance and integrity together
Indexes chosen against the queries that run, transactions where correctness demands them, and query plans read rather than guessed at when something is slow.
Related from Ekarche
Need your data modelled properly?
Tell us what the data has to represent and how it will be queried. We will model it on PostgreSQL to stay correct and fast as it grows.