metagration VS pg_partman

Realtime uses logical replication, and from your link it looks like it should work with Timescale (although not recommended):

> Using logical replication with TimescaleDB is not recommended, as it requires schema synchronization between the primary and replica nodes and replicating partition root tables, which are not currently supported.

As long as logical replication is supported, this won't be an issue for Realtime because the purpose is to receive data changes (which come in a JSON format) and the end-user doesn't need to persist schema modifications.

> but couldn't get it working

If you send me some error logs, I can take a look or forward to one of the team.

> support Postgres streaming replication

This is the first time I've heard it requested - I don't think it's something we'd do unless there was a good reason and strong demand. If we were to do any work in this direction we'd prefer to try contribute DDL streaming to PostgreSQL's logical streaming. We've been thinking about this for a while (Michel has built metagration - https://github.com/michelp/metagration which has prompted a few ideas for core patches)

Assuming these are the types of insights you're looking for, you'll probably look for a way to aggregate data points across/within geographies. postgis is an open source extension for postgres that can help you with this, but there's also quite a few python tools that can help you explore the data, such as geopandas, folium, geoplot. Depending on volume, you might want to partition the data for query performance, and there's another extension pg_partman that can help with that. Just noticed some other posts have recommended something similar.

pg_partman is in RDS >12.5 (here). Pg_partman makes managing data retention relatively easy.

Whenever I see these posts from TimescaleDB, I always want to ask them how it compares in performance to alternative extensions that implement the same features, rather than just comparing TimescaleDB to vanilla PostgreSQL.

For example, they mention their automated data retention and how it's achieved with one SQL command, and how DELETEing records is a very costly operation, and how "even if you were using Postgres declarative partitioning you’d still need to automate the process yourself, wasting precious developer time, adding additional requirements, and implementing bespoke code that needs to be supported moving forward".

There's zero mention anywhere of pg_partman, which does all of these things for you equally as simply, and is a fully OSS free alternative [0].

I get that it's a PG extension that competes with their product. I know that TimescaleDB does a few other things that pg_partman does not. But I can't help but find its (seemingly) purposeful omission in these, otherwise very thorough blog posts, misleading.

[0] https://github.com/pgpartman/pg_partman/blob/master/doc/pg_p...

Take a look into this extension which would take care of a good amount of automation for you.

You might want to look into pg_partman which has many useful tools around semi-automatic partitioning. According to their documentation they already have a procedure that will do exactly that: create new partitions based on the rows in the default partition.