[deobald]

I get the impression this was discovered in the Endatabas bibliography, since the same user just posted a link to the quickstart.

https://www.endatabas.com/bibliography.html

...Copeland's paper is a fun and inspirational read. If you enjoy that, you'll probably enjoy other papers from this list.

[1oooqooq]

Did you use it or are involved in the project?

wonder how it compares with postgre temporal table or just adding a `entity_history` somewhere. Or the timeline data is more intrinsic to the DB design on this one?

[deobald]

I'm involved in the project.

The temporal columns are intrinsic to Endb, but they are completely optional. By default, Endb queries run as-of-now, which then return the same results one would expect from a regular Postgres database.

Postgres temporal tables can't make Postgres natively aware of time, so temporal queries tend to be awkward, even if you want the default as-of-now result.

There are temporally-aware databases (SAP HANA, MySQL, SQL Server), but they all treat time as an additional concept layered on top of SQL-92 via SQL:2011. It's difficult for a mutable database to assume immutability or a timeline without becoming another product.

`entity_history` and similar audit tables aren't comparable at all, since they don't even involve the same entity/table, which means all querying of history is manual. Indexing of audit tables is at least a bit easier than the SQL:2011 temporal solutions mentioned above, though.

In all these cases, schema is still an issue that needs to be resolved somehow, since (again) incumbent relational databases assume a Schema First approach to table layout. Endb is Schema Last and allows strongly-typed nested data by default.

The Endb demo is pretty recent, and explains all of this in more detail, with examples:

https://www.youtube.com/watch?v=oDHGjUMqPvI