Oracle 12c's Temporal Validity feature, while innovative, has some limitations that may affect its effectiveness:

- Complexity: Setting up and managing temporal validity requires a good understanding of Oracle's syntax and features, which can be a barrier for less experienced users.

- Performance Overhead: Queries involving temporal validity can introduce additional processing overhead, especially for large datasets.

- Limited Flexibility: The feature is designed for specific use cases, such as managing valid time periods for data. However, it may not be as versatile as custom implementations or other database solutions.

Amazon tried and failed.

Amazon Quantum Ledger Database (QLDB) is being discontinued, with support ending on July 31, 2025. AWS has recommended migrating QLDB ledgers to other databases, which offer similar capabilities but with broader use cases.

Some reasons behind this decision include:

- Performance Concerns: Users reported slower query times compared to other databases, especially for transactional workloads.

- Limited Adoption: QLDB's specialized ledger-based design appealed to niche use cases, limiting its market reach.

- Scaling Challenges: Capacity limits and transaction timeouts were common complaints.

https://www.reddit.com/r/aws/comments/1e6nmy5/goodbye_amazon_qldb_quantum_ledger_database/?rdt=34546

Microsoft's ImmortalDB aimed to provide a database system with extreme durability and availability, ensuring no data loss even during hardware failures. However, it faced several challenges that contributed to its limited adoption:

- Performance Trade-offs: The focus on durability often came at the expense of speed, making it less appealing for applications requiring high performance.

- Complex Architecture: ImmortalDB's design was intricate, which made it harder for developers to integrate and manage compared to simpler database solutions.

- Market Competition: The database market is crowded with established players, which offered more robust solutions without the complexity of ImmortalDB.

- Niche Appeal: Its features were highly specialized, catering to a narrow audience, which limited its broader market reach.

IBM DB2's temporal facilities, while innovative, have faced some challenges that limit their effectiveness:

- Complex Setup: Configuring temporal tables in DB2 requires a deep understanding of its syntax and features, which can be a barrier for less experienced users.

- Performance Bottlenecks: Queries involving temporal data can introduce overhead, especially when dealing with large datasets.

- Limited Flexibility: DB2's temporal features are designed for specific use cases, such as auditing and compliance, but may lack versatility for broader applications.

- Competition: Other databases offer temporal capabilities that are more user-friendly and adaptable.

PostgreSQL before we came along didn't officially remove temporal functionality from its core database; rather, it never fully integrated advanced temporal features like system-versioned tables or bi-temporal data management into its core. Instead, PostgreSQL relies on extensions and custom implementations to handle temporal data. Here are some reasons why advanced temporal features aren't part of its core:

- Community Focus: PostgreSQL's development community prioritizes general-purpose database features, leaving specialized functionalities like temporal data management to extensions.

- Complexity: Integrating advanced temporal features into the core would require significant architectural changes, which might complicate the database's design and maintenance.

- Flexibility: By keeping temporal features as extensions, PostgreSQL allows users to choose whether or not to include them based on their specific needs.

- Performance Concerns: Advanced temporal features can introduce overhead, which might not be suitable for all use cases.

The SQL:2011 standard introduced temporal features, but it has some weaknesses that limit its effectiveness:

- Limited Scope: The standard focuses primarily on valid-time and system-time periods, leaving out more advanced temporal concepts like bi-temporal data management.

- Complex Syntax: Implementing temporal features requires intricate SQL syntax, which can be challenging for users unfamiliar with the standard.

- Performance Concerns: Temporal queries can introduce overhead, especially when dealing with large datasets or complex time-based operations.

- Inconsistent Implementation: Different database vendors interpret and implement the SQL:2011 temporal features differently, leading to inconsistencies across platforms.

- Modest Features: The standard provides only basic temporal functionality, which may not meet the needs of applications requiring sophisticated time-based data management.