The error you're encountering, "Incorrect timestamp precision for timestamp(6); the configured precision is MILLISECONDS; column name: bucket_start," is related to a known issue with timestamp precision in certain data warehouses, including Trino (and Athena). The problem arises because the data contains timestamps with microsecond precision (timestamp(6)), but the warehouse (Trino, in this case) is configured to support only millisecond precision (timestamp(3)). This issue has been reported in both Trino and Athena environments when running Elementary models, especially when using CTAS (Create Table As Select) statements. The error typically occurs on columns like bucket_start, bucket_end, or detected_at, which are used by Elementary for metrics and anomaly detection tables. Key points from the knowledge sources: - Athena and Trino (with Hive or Delta Lake catalogs) enforce millisecond precision for timestamps, and will throw an error if the data or table definition uses higher precision (microseconds) [Bug: Creating Elementary models fails on Athena Engine V3](https://github.com/elementary-data/elementary/issues/1678), [dbt-elementary's

metadata

table fails to create with dbt-trino with a Delta Lake catalog](https://github.com/elementary-data/elementary/issues/1648). - The error message and stack trace you provided match those described in the issues above. - The recommended workaround in Athena is to cast the timestamp columns to the supported precision (timestamp(3)), but there is no explicit solution documented for Trino in the knowledge sources. - This is a limitation of the underlying data warehouse, not specifically Elementary, but it affects Elementary's ability to create its models and tables. What you can do: - There is no direct fix documented in the knowledge sources for Elementary 0.18.3 and Trino. However, the general approach is to ensure that any timestamp columns in your models are cast to the supported precision (timestamp(3)) before table creation. - If you have control over the dbt models or can customize the Elementary package, you may need to modify the relevant models or macros to cast timestamp columns accordingly. - If this is a blocker, consider reaching out to the Elementary community or opening an issue, referencing the similar problems in Athena and Trino as described above. Summary: This is a known compatibility issue between Elementary and Trino (and Athena) regarding timestamp precision. The knowledge sources do not provide a ready-made solution for Trino, but the root cause and context are well-documented. You may need to adjust your models to cast timestamps to millisecond precision or wait for an upstream fix in Elementary or dbt for Trino support. If you need more detailed guidance on how to implement the casting workaround, please let me know!

Thank you for your follow-up. Based on the knowledge sources provided, the specific issue of "Incorrect timestamp precision for timestamp(6); the configured precision is MILLISECONDS" has been reported and discussed in several contexts, particularly for Athena and Trino. In the case of Athena, the issue was documented and a workaround was discussed, but the root cause is a limitation in the data warehouse's support for timestamp precision. The [Athena Engine V3 release notes](https://github.com/elementary-data/elementary/issues/1678) clarify that Athena (and by extension, Trino with similar storage backends) only supports millisecond precision, and queries or table creations with higher precision (microseconds) will fail. In the referenced [Github issue for Athena](https://github.com/elementary-data/elementary/issues/1678), the user ultimately closed the issue after discovering that a global materialization config in their dbt project was affecting Elementary models. The user did not indicate that a code fix in Elementary itself resolved the timestamp precision problem; rather, the issue was resolved by adjusting their own configuration: > There was a global materialization config that affected Elementary models. Closing. For Trino, a similar issue is mentioned in [another Github issue](https://github.com/elementary-data/elementary/issues/1648), but there is no explicit statement in the knowledge sources that a fix has been merged into Elementary to handle timestamp precision for Trino. The issue for Trino remains open, and the workaround involves manually ensuring timestamp columns are cast to the correct precision. In summary: While the Athena issue was closed due to a user-side configuration fix, there is no clear evidence in the knowledge sources that a general fix for Trino timestamp precision has been merged into Elementary. If you are still experiencing this error on Trino with Elementary 0.18.3, it is likely that the underlying limitation or required workaround still applies, and you may need to adjust your dbt or Elementary model configurations accordingly. If you believe this should be fixed in the latest version and it is not, it may be worth reopening or commenting on the relevant Github issue. If you have a specific Github issue number or link for Trino that you believe was fixed, please share it, and I can review it in detail. Otherwise, based on the sources above, the Trino issue does not appear to be fully resolved in Elementary as of now.