PostgreSQL

PostgreSQL data model design

The data layer in Release Coach AI, Inspire Film and Reveal Software sits on PostgreSQL. In the products where we use Supabase, PostgreSQL is underneath there too.

The data model is the most expensive decision to change in a product. You can rewrite an interface in a week, but migrating a badly shaped schema takes months. That is why we never leave this decision to automated generation.

01

Why a human designs the schema

AI can produce a schema that works, but it does not know where the product is heading in two years. Tenant separation, soft deletes, currency fields and which time zone your timestamps are stored in are the decisions that are hardest to correct later. An engineer designs these tables, and generated migration files are read line by line before they are merged. This is the one part of the stack where being slow up front is genuinely cheap.

02

Isolation in multi-tenant systems

In Reveal Software, every customer's data lives in the same database but has to stay separated from everyone else's. Leaving that isolation to a filter in application code means one forgotten query is a data leak. Building isolation at the database level makes every query written afterwards safe by default. That also shrinks the risk surface of generated code, which matters more as a larger share of the code is written with AI assistance.

03

An ORM does not think about indexes for you

Using Drizzle or a similar layer makes queries easier to write, but it does not remove the need to decide which column gets indexed. Most screens that slow down as record counts grow are slow because of a missing index. We identify the frequently run queries in advance and define indexes around them, so slowness is not discovered through a customer complaint six months after launch.

04

Backups and rehearsing the restore

Taking a backup is not enough. Until you have tried restoring one, you do not know whether you have a backup at all. At handover we leave the recovery steps in writing. Migrations being reversible matters just as much, because a bad migration is one of the fastest ways to do damage in production, and the middle of an incident is a poor time to work out how to undo it.

Questions

The things people ask before starting.

PostgreSQL or a document database?

If your data has relationships and you need reporting, we recommend PostgreSQL. Relational structure is hard to add later and easy to relax. Most projects that start schemaless discover a need for relationships within a year of launching.

Will you review and improve our existing database?

Yes. We work through the schema, indexes, slow queries and access permissions, then produce written recommendations. This normally runs under the ongoing support arrangement, which starts at $800 a month for 20 hours.

How do you manage data migrations?

Migrations are kept in version control and run against a copy before they reach production. We do not merge a migration that has no rollback step, regardless of how straightforward it looks at the time of writing.

Does our data stay with us?

Yes. Infrastructure is set up in your accounts and ownership stays with you. We do not build structures that create a dependency on us after handover, because that is not a healthy basis for a partnership.

Contact

Looking for an engineering partner for the long haul?

A short note about the product, the timeline and who it is for is enough to start. You will hear back from the engineer who would do the work, not a sales team.

Ankara / Türkiye · Working across European and US time zones