TimescaleDB VS temporal_tables

Don't forget PostgreSQL extensions. For something like a chat log, TimescaleDB (https://www.timescale.com/) can be surprisingly efficient. It will handle partitioning for you, with additional features like data reordering, compression, and retention policies.

Offboard it to Postgres specialists like https://www.timescale.com/

TimescaleDB{:target="_blank"}: an extension of PostgreSQL that adds time-series capabilities to the relational database model. It provides scalability and performance optimizations for handling large volumes of time-stamped data while maintaining the flexibility of a relational database.

Have some experience with https://www.timescale.com in this context

What about getting in touch with commercial organisations that have products/services based on PostgreSQL? For example Timescale, EDB, and Citus Data, or really any hosting provider that offers a managed PostgreSQL service.

There is Timescale.

Friends don't let their friends choose Mysql :)

A super long time ago (decades) when I was using Oracle regularly I had to make a decision on which way to go. Although Mysql then had the mindshare I thought that Postgres was more similar to Oracle, more standards compliant, and more of a real enterprise type of DB. The rumor was also that Postgres was heavier than MySQL. Too many horror stories of lost data (MyIsam), bad transactions (MyIsam lacks transaction integrity), and the number of Mysql gotchas being a really long list influenced me.

In time I actually found out that I had underestimated one of the most important attributes of Postgres that was a huge strength over Mysql: the power of community. Because Postgres has a really superb community that can be found on Libera Chat and elsewhere, and they are very willing to help out, I think Postgres has a huge advantage over Mysql. RhodiumToad [Andrew Gierth] https://github.com/RhodiumToad & davidfetter [David Fetter] https://www.linkedin.com/in/davidfetter are incredibly helpful folks.

I don't know that Postgres' licensing made a huge difference or not but my perception is that there are a ton of 3rd party products based on Postgres but customized to specific DB needs because of the more liberalness of the PG license which is MIT/BSD derived https://www.postgresql.org/about/licence/

Some of the PG based 3rd party DBs:

Enterprise DB https://www.enterprisedb.com/ - general purpose PG with some variants

Greenplum https://greenplum.org/ - Data warehousing

Crunchydata https://www.crunchydata.com/products/hardened-postgres - high security Postgres for regulated environments

Citus https://www.citusdata.com - Distributed DB & Columnar

Timescale https://www.timescale.com/

Why Choose PG today?

If you want better ACID: Postgres

If you want more compliant SQL: Postgres

If you want more customizability to a variety of use-cases: Postgres using a variant

If you want the flexibility of using NOSQL at times: Postgres

If you want more product knowledge reusability for other backend products: Postgres

TimescaleDB is Postgres with extensions to automatically partition tables for fast processing of time series data.

There is also the temporal_tables extension.

[0] https://github.com/arkhipov/temporal_tables

- https://github.com/arkhipov/temporal_tables

I haven't used any of these but I work on https://xtdb.com which is also implementing SQL:2011's temporal features :)

It seems like PG has this extension here anyone ever use it?

You could look at that or ask me questions about it (disclaimer, I am the author). Also there is https://github.com/arkhipov/temporal_tables/

All good. Note there is also https://github.com/arkhipov/temporal_tables/ (which is also type 4 as a postgres extension - pretty similar to what ebean orm is doing)

The Temporal Tables Postgres extension works well. https://github.com/arkhipov/temporal_tables

If you're doing this across regions, you really really should reconsider. If you're doing it in the same data center you might be able to get away with it (but then I'm not sure why you're doing it in the first place, if the system fits in one DC then you probably can just scale up). It might be worth considering a sharded & passively combined approach -- i.e. every country has it's own data, and there's some huge public schema which consists of all the data that is drip fed in to materialized views or tables at regular intervals. You could also combine this with temporal_tables to get a very delayed but theoretically time-consistent (well, aside from clock skew across regions of course...) view of your DB to query... Really depends on the use case.

One of postgres's most underrated features. RLS is amazing, can be unseen/basically work silently if your programming language-side tools are good enough, and is documented well (like everything else):

https://www.postgresql.org/docs/current/ddl-rowsecurity.html

But the power of PG is that it doesn't stop there, if you combine this with a plugin like temporal_tables and you can segment by user and time:

https://github.com/arkhipov/temporal_tables

All of this mostly unknown to the thing that's accessing the DB. If that's not enough for you, why not add some auditing with pgaudit:

https://www.pgaudit.org/#section_three

I think it might not actually be hyperbole to say that Postgres is the greatest RDBMS database that has ever existed.