back
1 comments
Postgres is incredibly flexible and scales beyond what most projects will ever need. We use it both as a very large scale CMDB store for https://turbot.com and as an small embedded DB for https://steampipe.io.

Use cases where we hit road bumps earlier were:

1. High churn data. Postgres copies data for each rite update and then vacuums to clean the old versions. These use cases dominated our DB load and moving them out helped a lot.

2. Large JSON blobs. Postgres automatically compresses and will pull large (~>8kB) columns into a separate “toast” table. This makes sense but also means they are often a real bottleneck if you expect to work with larger JSON blobs as you core model. pg is great for JSON, but if you are using it at scale do pre-work and testing of this factor and how it plays with your model.

3. Of course, long term archive of data objects is much more cost efficient and scalable in an object store like S3.

Bet on Postgres. Whatever you use case it will work great until you are large enough to really understand your data and optimize for your business.

Even in cases for regional replication?

Because this is the use case I am looking for, something like Spanner but cheaper.

Cross-region replication of data is always significantly harder, definitely consider if cross-AZ would be sufficient for your case (which it often is). Postgres can definitely be configured for a cross-region scenario, but the approach varies a lot depending on your recovery needs.