Ok but XTDB has a lot in common with Datomic and is open source but still hardly widely used. I think this is partly because most people don't consider 'temporality' as a feature a database should offer; rather, they believe temporal problems should be solved via proper schema design and application logic. Additionally, using datalog (or any esoteric query language that isn't SQL) locks you out of many battle-tested tools that enterprises rely on.
The XTDB team has pivoted towards a SQL-first approach (though still supports datalog) and now 'only' has the 'But why not just use Postgres' problem to solve.
Having personally moved from trying to use Postgres for everything (including lots of timeseries data with Timescale) to a dedicated and relatively unknown DB built purely for the purpose I want it for (QuestDB), I am all for more people trying to build databases that do specific things better than Postgres. However, it will be very difficult to create something that does literally everything Postgres can do but better, which probably makes Postgres the sensible choice for the majority of applications.
> this is partly because most people don't consider 'temporality' as a feature a database should offer
Not sure on your definition of 'people', but I think every business ultimately wants solid auditing and reporting capabilities across their IT systems.
These concerns are only increasing in importance as new regulations demand stronger data provenance, but their implementation shouldn't be reliant on the process of "proper schema design" to get things right first time.
Databases built for the modern world should be making this stuff bulletproof and easy.
(I work on XTDB - and if Postgres already supported temporal tables I possibly wouldn't!)
Oh, I totally agree that 'people' (which I guess refers to any potential user of a DBMS) often do need temporality (or even bitemporality), but they don't consider that the database should have this baked in, or they just don't consider it much at all.
I'm fully on board with XTDB and similar solutions for this reason. Most people still gravitate towards Postgres and similar databases without giving much thought to these temporal challenges, even though those options lack a robust solution for the temporal issues that so many systems demand.
The XTDB team has pivoted towards a SQL-first approach (though still supports datalog) and now 'only' has the 'But why not just use Postgres' problem to solve.
Having personally moved from trying to use Postgres for everything (including lots of timeseries data with Timescale) to a dedicated and relatively unknown DB built purely for the purpose I want it for (QuestDB), I am all for more people trying to build databases that do specific things better than Postgres. However, it will be very difficult to create something that does literally everything Postgres can do but better, which probably makes Postgres the sensible choice for the majority of applications.