Database design and engineering
We design the data layer to hold up — schemas modelled on how the business actually works, on Postgres, with migrations that ship without downtime and integrity enforced by the database, not by hope.
A schema is the one part of a product that is genuinely hard to change later, because everything else comes to depend on its shape. So it is worth getting right the first time: the entities modelled as they really relate, the constraints that make a bad row impossible rather than merely discouraged, the indexes that keep a query fast when the table is a thousand times larger than it is today.
We work in Postgres by default, and we treat migrations as first-class engineering — versioned, reversible, and applied without taking the product offline. It is the same data discipline underneath Lekha, where a two-sided ledger has to reconcile to the rupee across suppliers and buyers and never quietly lose a bill.
What the data layer needs
-
Modelling that matches the domain
A schema shaped by how the business actually works — the real entities and their real relationships — so the data is queryable the way people need to ask about it, not contorted to fit a framework.
-
Integrity in the database
Constraints, foreign keys, and transactions that make invalid data impossible to write, rather than a validation the application layer might one day forget to run.
-
Migrations without downtime
Schema changes shipped as versioned, reversible migrations that apply while the product stays up — so evolving the data layer is routine, not an outage waiting to be scheduled.
Related from Ekarche
Need the data layer done right?
Tell us what the product has to store and how it will be asked about. We will design a schema that stays correct and stays fast as the data grows underneath it.