pg_timetable VS tidb

That's easily done with a cron job or something similar (e.g. pg_timetable)

When you are working on Oracle to PostgreSQL migrations, one of the Oracle packages that cause conversion issues is DBMS_JOB. Traditionally, we used extensions like : pg_agent, pg_cron or more recently pg_timetable for scheduling jobs. All of these tools or extensions use a cronjob like scheduling method which does not give a full compatibility of the features provided by Oracle DBMS_JOB. Translating calls to DBMS_JOB.SUBMIT() into a cron setting is more painful than being impossible when there is an execution interval lesser than a minute. There are several such DBMS_JOB compatibility issues including asynchronous scheduling which is not possible with the already existing extensions in PostgreSQL. MigOps hates to stay without Open Source solutions. So, we are announcing PG_DBMS_JOB extension for Oracle DBMS_JOB compatibility, released under PostgreSQL License. An interesting point here is that we have included full compatibility of Oracle DBMS_JOB in PG_DBMS_JOB PostgreSQL extension.

If you don't want to (or can't) use the Windows Scheduler, you might want to try out pg_timetable instead, which also offers Windows binaries.

Try pg_timetable

You better send emails periodically with cron-like scheduler. This one can do both cron and periodical jobs: https://github.com/cybertec-postgresql/pg_timetable

tidb has been around for a while, it is distributed, written in Go and Rust, and MySQL compatible. https://github.com/pingcap/tidb

Somewhat relatedly, StarRocks is also MySQL compatible, written in Java and C++, but it's tackling OLAP use-cases. https://github.com/StarRocks/starrocks

It's MySQL-Compatible database for scale and real-time analytics https://github.com/pingcap/tidb

PingCAP | https://www.pingcap.com | Database Engineer, Product Manager, Developer Advocate and more | Remote in California | Full-time

We work on a MySQL compatible distributed database called TiDB https://github.com/pingcap/tidb/ and key-value store called TiKV.

TiDB is written in Go and TiKV is written in Rust.

More roles and locations are available on https://www.pingcap.com/careers/

Pesquise por CockroachDB ou TiDB

OLTP usually comes with high throughput of transactions, which means usually write(e.g., IUD - insert, update, delete) to read (e.g., select) ratio is above 4 or 5 or even higher. There are some good benchmarks to test OLTP workload like TPC-C (https://www.tpc.org/tpcc/), and some benchmarks to test OLAP workload like TPC-H (https://www.tpc.org/tpch/). For mixed or hybrid OLTP and OLAP (it's called HTAP, see this blog for some background https://en.pingcap.com/blog/the-beauty-of-htap-tidb-and-allo...), TPC-H was originally designed for this, however, it actually doesn't reveal the real world workload with several drawbacks. A newer research work from UC Berkeley proposed a HTAP benchmark called TAOBench (https://www.vldb.org/pvldb/vol15/p1965-cheng.pdf) which is pretty interesting and worthy to check.

For the HTAP systems, as mentioned in the above blog, there are quite a few industrial products, like Google just announced AlloyDB (https://cloud.google.com/alloydb), Snowflake's UniStore (https://www.snowflake.com/workloads/unistore/), and one of the most popular open source projects TiDB (https://github.com/pingcap/tidb) which have been deployed by many business applications.

Hopefully these may help a little bit :-)