[dewey]

I'd say Postgres is very often the right choice for newer company as it's well understood, easy to operate and you know you don't have to switch to a new DB because the vendor got acquired / merged / shutdown after 2 years or is going through growing pains and deprecations themselves.

If you give your schema a good thought (The one place where you shouldn't rush and take shortcuts at the beginning) and for example use jsonb columns and later move data out of it if you notice you need to query on it more performantly you can get very far.

The pain of data model migrations is also usually not that big if the company isn't very large and has a lot of legacy yet.

[sgarland]

> give your schema a good thought

> use jsonb columns

These two statements are mutually exclusive in most cases. If you want JSON, don’t use a relational database.

IME, the “we’ll normalize this later” event never occurs.

[dewey]

Not really, it doesn't mean you put everything into a jsonb field. It could mean that for example if you have some user specific settings you just drop them in a jsonb on the user itself instead of building a schema with mapping tables, permissions etc. as you don't know yet which options you want to support. Once thing stabilize you can pull it out of there.

From my personal experience this works really well and is a nice balance between a strict schema, and still allowing some flexibility for experiments.

[sgarland]

This will work, but you risk referential integrity violations, as well as performance problems at scale.

The main issue is what I said in “IME…” – tech debt builds, and people never want to go back and fix it. Just upsize the hardware, easy-peasy.

I would rather see a wide table with a bunch of bools indicating various options, personally. When that gets annoying or unperformant, split it out into logical groups. Color schemes can be their own table, email marketing preferences can be their own table, etc.

[dewey]

Which is precisely the caveat I mentioned at the beginning:

> and for example use jsonb columns and later move data out of it if you notice you need to query on it more performantly you can get very far.

If you put data inside where you want the database to enforce integrity...then it's the wrong place for the data. If you are getting problems on scaling, you are relying on data in jsonb columns for heavy queries which you should not. In that case it should've been moved out already.

As always it's about tradeoffs and being pragmatic. There's no 100% way of saying jsonb is always the wrong choise, or always the right choice. You still have to be smart about when to reach for it.

> I would rather see a wide table with a bunch of bools indicating various options, personally. When that gets annoying or unperformant, split it out into logical groups. Color schemes can be their own table, email marketing preferences can be their own table, etc.

The point is to exactly avoid this kind of overhead when you have zero paying customers, as that's premature optimization. Of course from a pure data model perspective it's nice, but from a business perspective you don't need that until it hurts and you have to split it out.

[sgarland]

> The point is to exactly avoid this kind of overhead when you have zero paying customers, as that's premature optimization.

It should take a day at most to work out the data model for a startup. I don’t see that as a lot of overhead.

Do as you will, but from my perspective, I’d rather do it correctly from the start.